DComTalk.com

by **J. Clarke** » Thu Sep 29, 2005 11:20 am

James Knott wrote:

J. Clarke wrote:

I'm not sure I understand why this would prevent the ISP from providing
individual addresses. Are you saying that it is technologically
impossible for them to block all MAC addresses other than those that you
are paying for the privilege of using?

While it may be possible to filter out all but one unique address, judging
from what I've been reading, they're not supposed to.

Supposed to according to who? It being in a standard won't prevent them if
they think it will make them a buck.

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

by **James Knott** » Thu Sep 29, 2005 11:20 am

J. Clarke wrote:

I'm not sure I understand why this would prevent the ISP from providing
individual addresses. Are you saying that it is technologically
impossible for them to block all MAC addresses other than those that you
are paying for the privilege of using?

While it may be possible to filter out all but one unique address, judging
from what I've been reading, they're not supposed to.

by **James Knott** » Thu Sep 29, 2005 11:20 am

Robert Redelmeier wrote:

James Knott <james.knott@rogers.com> wrote:
It's already in use in Asia and the U.S. government has made
support for it mandatory in a couple of years. Also, Linux
routers can already handle it and I'd imaging Cisco etc.,
should be able to with a software upgrade, if they're not
already able to.

Yes, but each packet will take more work to process.
More header, 16 bytes of address rather than 4. That will
take upto 4x longer on 32bit routing machines.

CPUs are quite powerful these days, not like the old days, when routers were
16 bit minicomputers. Also, the standard length headers and extension
headers make it easier for routers.

There are other advantages, besides the larger address
sizes. Standard size headers make routing easier, along
with improved QoS support and others.

QoS? Isn't that equivalent to "drop if congested"? :)

No, it refers to various priorities, as determined by the app.

by **James Knott** » Thu Sep 29, 2005 11:20 am

J. Clarke wrote:

While it may be possible to filter out all but one unique address,
judging from what I've been reading, they're not supposed to.

Supposed to according to who? It being in a standard won't prevent them
if they think it will make them a buck.

According to the IETF. Also, what's there to sell? The number of addresses
is incredibly huge and even today, IPv4 doesn't keep people from running
multiple computers over a single IP. An ISP doesn't control the last 48
bits of an address, the customer does. This means the ISP would have to
actively block any address to other than the "official" MAC address that
the customer has.

by **James Knott** » Thu Sep 29, 2005 11:20 am

Robert Redelmeier wrote:

IPv6 needs a "killer app."

Bingo! Change doesn't happen without drivers. Carrot works better than
stick. Markets are hard to coerce. Monopolies considerably easier.

Just look at the FCC failure on HDTV. In constrast DVD has overtaken
VHS not because of convenience and production cost, but due to a
surprising quality improvement. Who dreamed NTSC could look so good?

There are a couple of things driving IPv6. The most obvious is limited
addresses in IPv4. According to what I read a while ago, the number of
IPv4 addresses assigned to China, would be insufficient for a large ISP in
North America! They'll be needing a lot more addresses than can be
supported in IPv4. Also, I read something about Nokia using IPv6 for cell
phones etc. Again there aren't enough IPv4 addresses to meet their needs.
And of course, we can't forget about our networked toasters and coffee
pots. ;-)

IPv6 also supports encryption and authentication, by default. The extention
headers make it easier to support new protocols etc.

by **James Knott** » Thu Sep 29, 2005 11:20 am

Robert Redelmeier wrote:

CPUs are quite powerful these days, not like the old days,
when routers were 16 bit minicomputers. Also, the standard
length headers and extension headers make it easier for routers.

Yes, CPUs are more powerful. But the bottleneck is now in memory
transfer in&out. That bandwidth has improved, but latency and
bus contention has not much. Longer will take more time.

One other thing they're trying to do, is arrange addresses geographically,
so you'd have, for example, a route to Europe and only once there, worry
about what country etc. This should cut down considerably on routing
tables.

by **Robert Redelmeier** » Thu Sep 29, 2005 11:20 am

James Knott <james.knott@rogers.com> wrote:

CPUs are quite powerful these days, not like the old days,
when routers were 16 bit minicomputers. Also, the standard
length headers and extension headers make it easier for routers.

Yes, CPUs are more powerful. But the bottleneck is now in memory
transfer in&out. That bandwidth has improved, but latency and
bus contention has not much. Longer will take more time.

QoS? Isn't that equivalent to "drop if congested"? :)

No, it refers to various priorities, as determined by the app.

You missed the smiley. The app can put on whatever priorities
it likes. What matters is how the network reacts.

-- Robert

by **Robert Redelmeier** » Thu Sep 29, 2005 11:20 am

Rick Jones <rick.jones2@hp.com> wrote:

IPv6 needs a "killer app."

Bingo! Change doesn't happen without drivers. Carrot works better than
stick. Markets are hard to coerce. Monopolies considerably easier.

Just look at the FCC failure on HDTV. In constrast DVD has overtaken
VHS not because of convenience and production cost, but due to a
surprising quality improvement. Who dreamed NTSC could look so good?

-- Robert
>

by **Guest** » Thu Sep 29, 2005 11:20 am

Vernon Schryver wrote:

In article <AEH_e.13432$6T1.3210@news.cpqcorp.net>,
Rick Jones <rick.jones2@hp.com> wrote:

*) devices that operate at the physical layer (eg electrical/optical)
are repeaters (a "hub" being a multi-port repeater :)

*) devices that operate at the data-link layer (eg MAC) are bridges
(a "switch" simply a multi-port bridge :)

yes, like Kalpana.

*) decices that operate at the network layer (eg IP) are routers

Many people used "gateway" for "router." Look for "gateway" in rfc-index.txt
Maybe they didn't want to get bogged down in arguments about the
right way to prounounce "router." See for example RFC 875, "Gateways,
Architectures, and Heffalumps" perhaps via
http://ietf.org/rfc.html

*) devices that operate at the transport layer and higher are gateways

I think more words are need to make the intended meaning clear,
as in ALG or application layer gateway.

coudl you refer me to any book on this? I have some network book but
none breka it down as clearly as that.

I would, but I'm not sure where I 'learned' that bit - it may be
collective wisdom from ages past,

I'd start by understanding the functions and worry about the labels
later. The labels are merely boring semantics or worse (e.g.
intentionally misleading marketing propaganda) if you know what the
boxes do. If you don't know the substance behind the labels, you
can only go wrong by using them.

but how to do test what the boxes do down to this level

you write elsewhere regarding what some boxes do

" run out of their own table space and crash or refuse to pass TCP
segments unless they've seen a 3-way handshake, which breaks TCP
connections when they're rebooted.) "

I guess you do this by telnetting and network sniffers and generating
packets.

Regarding Telnetting: it's tricky to find a command reference for
telnetting to any model of router. I managed to find DLink's one, but
not Linksys. (and i'm guessing that some more modern consumer routers
may not even provide a telnet interface).

Regarding Network Sniffers: 'home routers' tend to have a telephone
socket at the WAN end. so, any packet sniffer can only go on the 'your'
end.

Regarding Generating Packets: Since NAT devices only have 2
interfaces, and the WAN interface is a tel socket , the only way to
generate a packet from the WAN end is to have control of another
computer on the internet not connected to that network. (e.g. dial up
account, though in the UK local tel calls aren't free)

Thos are just my thoughts on possible methods. But, what methods do you
use?

by **Guest** » Thu Sep 29, 2005 11:20 am

Patrick Schaaf wrote:

James Knott <james.knott@rogers.com> writes:

Patrick Schaaf wrote:

My take: if it forwards IP frames, it is a router.

Actually, it's ethernet frames and IP datagrams.

Hmm, and what layer was 'packets', again? :)

There is a slight difference in the meaning of IP datagram and IP
Packet.
these words are used to describe the function of fragmentation. The
datagram is the packet to be fragmented, and the packets after they are
reassembled, form the original datagram. It's very clear terminology
used in discussing the function of fragmentation.

You seem to have more disdain for terminology than most that rsepodn on
usenet. I think the disdain is overdone, though I can see why you have
it.

The thought of reading or learning the functions a device, without
looking at the terminology, is alien to me, i've never done it before,
though I shall consider it.

When you get a device, e.g. a home router, and you want to see how it
functions, What do you do?

telnet to it(though where do you get he command ref from. Manufacturers
tend to hide it),

I suppose generating packets to throw at it and network sniffing would
tell you what goes in and out. So you can figure out some of its inside
functions.

I will look more at functionality now,

by **Rod Dorman** » Thu Sep 29, 2005 1:47 pm

In article <dhffi6$1ttp$1@calcite.rhyolite.com>,
Vernon Schryver <vjs@calcite.rhyolite.com> wrote:

In article <1127955131.428101.272000@g49g2000cwa.googlegroups.com>,
jameshanley39@yahoo.co.uk> wrote:
mainly because on comp.dcom.lans.ethernet there were many post on
ther that clarified that a (layer 2) switch is a marketting term for a
bridge with >2 ports. And a layer 3 switch is amarketting term for a
router.

I don't quite agree. "Switch" was originally a marketing term that
meant "fast Ethernet bridge." The number of ports was irrelevant,
...
Today everything is a "switch." Everything or close to everything is
...

I thought a "switch" was that thing on the wall you toggle to make the
lights turn on and off :-)

--
-- Rod --
rodd(at)polylogics(dot)com

by **J. Clarke** » Thu Sep 29, 2005 5:42 pm

Robert Redelmeier wrote:

Rick Jones <rick.jones2@hp.com> wrote:
IPv6 needs a "killer app."

Bingo! Change doesn't happen without drivers. Carrot works better than
stick. Markets are hard to coerce. Monopolies considerably easier.

Just look at the FCC failure on HDTV.

What "failure"? If you mean that everybody hasn't rushed out and gotten an
HD receiver, why should they if they don't want HD?

In constrast DVD has overtaken
VHS not because of convenience and production cost, but due to a
surprising quality improvement. Who dreamed NTSC could look so good?

Well, actually it's convenience and production cost. DVDs you can press in
one shot, tapes have to be recorded one bit a a time. And DVDs don't wear
out. DVD looks pretty crappy next to ATSC by the way.

-- Robert

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

by **Rick Jones** » Thu Sep 29, 2005 5:56 pm

Robert Redelmeier <redelm@ev1.net.invalid> wrote:

James Knott <james.knott@rogers.com> wrote:
CPUs are quite powerful these days, not like the old days,
when routers were 16 bit minicomputers. Also, the standard
length headers and extension headers make it easier for routers.

Yes, CPUs are more powerful. But the bottleneck is now in memory
transfer in&out. That bandwidth has improved, but latency and
bus contention has not much. Longer will take more time.

The smallest unit a CPU fetches from memory is a cacheline. These
days, 64 byte cachelines are common, as are 128 byte cache lines.
Some CPUs have automagic "buddy prefetch" that makes a 64 byte cache
line size behave more like 128. Etc etc etc...

So, all the headers from Ethernet, through IP, TCP and even a byte or
three of user data come in to the CPU when the NIC driver first looks
at the ethernet header. Just a little less of the user's data
comes-in with IPv6.

rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

by **Rick Jones** » Thu Sep 29, 2005 5:58 pm

In comp.dcom.lans.ethernet Vernon Schryver <vjs@calcite.rhyolite.com> wrote:

In article <AEH_e.13432$6T1.3210@news.cpqcorp.net>,
Rick Jones <rick.jones2@hp.com> wrote:
*) decices that operate at the network layer (eg IP) are routers

Many people used "gateway" for "router." Look for "gateway" in rfc-index.txt
Maybe they didn't want to get bogged down in arguments about the
right way to prounounce "router." See for example RFC 875, "Gateways,
Architectures, and Heffalumps" perhaps via
http://ietf.org/rfc.html

*) devices that operate at the transport layer and higher are gateways

I think more words are need to make the intended meaning clear,
as in ALG or application layer gateway.

Good point.

I would, but I'm not sure where I 'learned' that bit - it may be
collective wisdom from ages past,

I'd start by understanding the functions and worry about the labels
later. The labels are merely boring semantics or worse (e.g.
intentionally misleading marketing propaganda) if you know what the
boxes do. If you don't know the substance behind the labels, you
can only go wrong by using them.

Wouldn't labels be boring syntax rather than semantics?-)

rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

by **Rick Jones** » Thu Sep 29, 2005 6:02 pm

Patrick Schaaf <mailer-daemon@bof.de> wrote:

Hmm, and what layer was 'packets', again? :)

So, we have the application message, segmented into multiple TCP
segments, each contained in fragmented IP datagrams, contained in
ethernet frames that get chopped-up into cells and then aw heck just
say "The Vessel with the Pestle Holds the Pellet with the Poison,
the Chalice with the Pallace hold the Brew that is True"

:)

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

DComTalk.com

is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Re: is a NAT device/'home router' - a router?

Who is online