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

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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.

FWIW, at one point the U.S. Government mandated that systems they
bought support OSI

> 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.

You left-out that contemporary "consumer" OSes - perhaps for a fairly
broad definition back in time for "contemporary" - support IPv6.

> There are other advantages, besides the larger address sizes.
> Standard size headers make routing easier, along with improved QoS
> support and others. As I mentioned in another note, IP addresses
> include the MAC addresses. This means that as soon as a device is
> powered up, it already has a local network address. It will then
> find out what networks it's on, to determine other IP addresses. No
> need for DHCP or arp.

Is ND really a proper superset of DHCP? I thought I heard of some
DHCPv6 stuff out there - makes me wonder if everything devices get via
DHCP they can get via IPv6 ND?

IPv6 needs a "killer app."

rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
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...

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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.

> 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"?

-- Robert

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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?

I know my usage is a bit confused, there, so I thank you for this
correction. But I think I'm not alone, and this specific confusion
is even more widespread than the bridge/switch/router/gateway
confusion.

It's really a wonder we can all talk about the same technical reality.
Must have something to do with the extraordinary simplicity and constancy
of the basic networking functions which survived. We should all thank
the inventors of that reality, instead of confusing ourselves with words.

best regards
Patrick

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip (More info?)

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?

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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,

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip (More info?)

Vernon Schryver wrote:

> The good reason your box might support RIP is to advertise a default
> route to hosts on your home network.

How many hosts respond to RIP? If there's only one route to the internet,
there's no need for RIP.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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)

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

James Knott wrote:
> Vernon Schryver wrote:
>
> > The good reason your box might support RIP is to advertise a default
> > route to hosts on your home network.
>
> How many hosts respond to RIP? If there's only one route to the internet,
> there's no need for RIP.

no need for a routing table either if only one entry(though at least it
uses it). It dosen't even seem to use the routing protocol. But I
guess the reason it has these is that the technology is already around
and is no big deal to implement, since home routers already have their
own OS and web server built in. So, why not a routing table, and why
not a routing protocol like RIP that is just not being used. If the
router is built using things that already exist, then there's no point
removing the RIP or routing table from it.

Apparently even ethernet repeaters were built with old NICs , so I
guess the MAC address was ignored. Same principle. If the technology
is already there and not expensive, it's cheaper to use it as it is
use it as it is, and if there are unnecessary features, just let them
be and don't use them.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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
>

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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...

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip (More info?)

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...

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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...

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip (More info?)

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip (More info?)

In comp.dcom.lans.ethernet Rod Dorman <rodd@panix.com> wrote:

> I thought a "switch" was that thing on the wall you toggle to make the
> lights turn on and off 🙂

Nah, what your are thinking of is a layer one repeater with
user-enabled firewall functionality

rick jones
--
Process shall set you free from the need for rational thought.
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...