Sign in with
Sign up | Sign in
Your question

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

Last response: in Networking
Share
Anonymous
September 28, 2005 12:10:50 AM

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

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

I see that they receive a frame, and then forward it on to a local
computer. This isn't routing. Infact, I've heard that NAT is really a
firewall feature, and these devices do have built in firewalls.

And I can't see that these NAT devices have a routing table either.
When they send a frame out, they just send it down the wire, to the
ISP's router.

A 'home router' with its 2 arms and apparently no knowledge of teh
outside world, doesn't seem like a router to me.

But I've also heard that it uses RIP and us a router, it's hard to see
how or where. Or what is right
Anonymous
September 28, 2005 7:55:21 AM

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

Patrick Schaaf wrote:
> jameshanley39@yahoo.co.uk writes:
>
> >is a NAT device/'home router' - a router?
>
> It is.
>
> >I see that they receive a frame, and then forward it on to a local
> >computer. This isn't routing.
>
> It is routing when it has two interfaces. It could even be routing
> if there were only one interface. The essence of routing, is to
> look at the L3 header, and decide where the packet has to go to.
> Even if the decision appears to always be the same.

I think the essence of routing is
a)look at the dest ip
b)use the dest ip to consult a routing table
c)decide where the packet should go

In this case - for incoming packets, the Dest IP is always that of the
router itself. The router doesn't look at the Dest IP to see where the
frame should go. It looks at the TCP Port in the packet, and forwards
the packet accordingly.

less importantly, but furthermore, as I said, i've heard that NAT is a
firewall function rather than a router function. and the 'home routers'
do have built in firewalls.


<snip>

> >And I can't see that these NAT devices have a routing table either.
>
> Many of them run Linux with a normal Linux IP stack. You bet there's
> a routing table, somewhere!

If there's a routing table, what is in it? (I will speculate)

As far as I know, Port Forwarding has nothing to do with a routing
table. As far as I know, Routing tables don't mention the TCP Port.
They mention

Subnet, Next Hop, Router Interface

So are you saying that they have a routing table with a single entry
and the next Hop is the ISP's router?

This is all very well for outgoing frames. But incoming frames are not
routed. AFAIK NAT and port forwarding, have nothing to do with a
routing table.


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

This is your attitude speaking. You think that whether by port
forwarding or not, it is routing. But you don't consider words
important. You may be right about the forwarding being routing, or you
may be wrong. But you don't mind inventing words as you go along. I
clearly value correct terminology more than you do.

> BTW, words are irrelevant. The box works without them.

There are many like you. Most often people in marketting have tha
attitude to terminology.

Perhaps somebody that values terminology can respond to this post
regarding correct terminology!!!
Anonymous
September 28, 2005 11:13:16 AM

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

jameshanley39@yahoo.co.uk writes:

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

It is.

>I see that they receive a frame, and then forward it on to a local
>computer. This isn't routing.

It is routing when it has two interfaces. It could even be routing
if there were only one interface. The essence of routing, is to
look at the L3 header, and decide where the packet has to go to.
Even if the decision appears to always be the same.

What do you think a NAT device/'home router' is doing when,
from the internet, a packet arrives with a destination IP
which is not known on the LAN side? Leaving aside firewall
rules, I'd guess the packet would take the default route
straigt out the link it came in on.

What about the (not so uncommon) boxen with an additional WLAN
interface? Do they become a router when the WLAN is configured?
Or when the first station really connects to the WLAN? Do they
then stop being a router when somebody pulls the LAN cable?

>And I can't see that these NAT devices have a routing table either.

Many of them run Linux with a normal Linux IP stack. You bet there's
a routing table, somewhere!

Don't be blinded by the devices-for-dummies totally-dumbed-down
web interface those boxen present. That's just pretty packaging.

>A 'home router' with its 2 arms and apparently no knowledge of teh
>outside world, doesn't seem like a router to me.

You are entitled to use terminology all the way you like. You are also
entitled - guessing here - to play word definition games with your friends.

Even with a single physical arm, a thing can be a router. Think about
multiple VLANs on a single ethernet cable.

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

BTW, words are irrelevant. The box works without them.

best regards
Patrick
Related resources
Anonymous
September 28, 2005 3:08:23 PM

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

jameshanley39@yahoo.co.uk writes:

>I think the essence of routing is
>a)look at the dest ip
>b)use the dest ip to consult a routing table
>c)decide where the packet should go

>In this case - for incoming packets, the Dest IP is always that of the
>router itself.

When it's configured to do NAT, yes. Otherwise, no. So in general, no.

>[...] i've heard that NAT is a firewall function rather than a router
>function.

NAT is a function by itself. It is implemented and/or configured in
otherwise pure routers, in otherwise pure firewalls, or in any
combination thereof. No understanding is gained by calling it
'a router function' or 'a firewall function'. NAT is NAT.

>and the 'home routers' do have built in firewalls.

Part of the software and configuration can be called 'firewall'.
Just as other parts can be called 'router'.
And other parts can be called 'address translation'.

><snip>

>> >And I can't see that these NAT devices have a routing table either.
>>
>> Many of them run Linux with a normal Linux IP stack. You bet there's
>> a routing table, somewhere!

>If there's a routing table, what is in it? (I will speculate)

It will be a default route out the WAN interface, and one or more
connected routes towards internal networks. Depending on the feature
set of the configuration interface, it could also contain whatever
routes the local administrator desired.

>As far as I know, Port Forwarding has nothing to do with a routing
>table.

No dispute. But, after port forwarding or other forms of NAT have done
their packet manipulation, the resulting packet is usually routed as if
it were just arrived from the same interface as the original, unmangled
packet.

best regards
Patrick
Anonymous
September 28, 2005 4:16:51 PM

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

<jameshanley39@yahoo.co.uk> wrote in message
news:1127904921.081046.68950@z14g2000cwz.googlegroups.com...
>
> If there's a routing table, what is in it? (I will speculate)
>

No need to speculate. Here's a sample routing table from a Linksys
broadband router made circa 2000.

Destination LAN IP Subnet Mask Default Gateway Hop
Count Interface
0.0.0.0 0.0.0.0 64.x.x.x 1 WAN
64.x.x.x 255.255.240.0 0.0.0.0 1 WAN
192.168.10.0 255.255.255.0 0.0.0.0 1 LAN

One entry for the ISP's next-hop, one entry for each directly attached
network. Simple? Yes. Small? Yes. Still a routing table, still routing.
Anonymous
September 28, 2005 4:53:46 PM

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

jameshanley39@yahoo.co.uk wrote:

> is a NAT device/'home router' - a router?
>
> I see that they receive a frame, and then forward it on to a local
> computer. This isn't routing. Infact, I've heard that NAT is really a
> firewall feature, and these devices do have built in firewalls.
>
> And I can't see that these NAT devices have a routing table either.
> When they send a frame out, they just send it down the wire, to the
> ISP's router.

They perform a routing function, in that the local hosts send off network
traffic to the default route, which happens to be one of those boxes. The
only difference, is that those boxes also provide address translation.
Some of those boxes are capable of operating without using NAT.

>
> A 'home router' with its 2 arms and apparently no knowledge of teh
> outside world, doesn't seem like a router to me.

Even "real" routers, such as from Cisco, point to a default gateway, at the
ISP. They also have two or more ports.

>
> But I've also heard that it uses RIP and us a router, it's hard to see
> how or where. Or what is right
Anonymous
September 28, 2005 4:54:45 PM

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

Patrick Schaaf wrote:

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

Actually, it's ethernet frames and IP datagrams.
Anonymous
September 28, 2005 4:56:40 PM

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

jameshanley39@yahoo.co.uk wrote:

> I think the essence of routing is
> a)look at the dest ip

Also done by the host, to determine if local network or not.
> b)use the dest ip to consult a routing table

If there's only one possible destination (ISP gateway), there's nothing to
look up.

> c)decide where the packet should go
>
Anonymous
September 28, 2005 9:31:56 PM

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

Wayne wrote:
> <jameshanley39@yahoo.co.uk> wrote in message
> news:1127904921.081046.68950@z14g2000cwz.googlegroups.com...
> >
> > If there's a routing table, what is in it? (I will speculate)
> >
>
> No need to speculate. Here's a sample routing table from a Linksys
> broadband router made circa 2000.
>
> Destination LAN IP Subnet Mask Default Gateway Hop
> Count Interface
> 0.0.0.0 0.0.0.0 64.x.x.x 1 WAN
> 64.x.x.x 255.255.240.0 0.0.0.0 1 WAN
> 192.168.10.0 255.255.255.0 0.0.0.0 1 LAN
>
> One entry for the ISP's next-hop, one entry for each directly attached
> network. Simple? Yes. Small? Yes. Still a routing table, still routing

yes, btw, where did you get LinkSys command ref from? (note-I managed
to find DLink DSL504 here http://shadow.sentry.org/~trev/dsl50x.html)

it's interesting. My DLink DSL504 router actually doesn't list local
IPs in the routing table. I guess its NAT is implemented in the
firewall part.

There is only one entry in my router's routing table - that entry being
the default route.

192.168.0.1> ip route
route add ppp_route 0.0.0.0 82.70.237.22 00:00:00:00 1 0 1 #
MAN via ppp_device
192.168.0.1>

so, doesn't seem like much need to look up the dest ip. Doesn't look
like RIP is doing much.
If the Dest IP is its own IP, then NAT and PAT kicks in. And if it's
anything it just goes to the routing table and takes the default route,
which is out the WAN interface to the ISP's router.

But there are commands and ways in the web interface, to add entries.
THe web interface mentions 2 interfaces ISP1 and Ethernet (makes
sense).

I guess if I could disable NAT such that packets could arrive at my
router with an IP of one of my local computers, - then I could start
adding entries to the routing table.

though with NAT, and this one WAN interface for the default route
entry. The whole RIP (that seems to advertise nothing - what subnets
are connected at my end to my router, that it would advertise? None-
The one subnet that it has at my end is NATed anyway - not advertised)
and Routing Table(with the 1 default entry) seems like overkill!

But I guess it's still techically a rouiter, for its RIP and routing
table.
Anonymous
September 28, 2005 9:52:11 PM

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

Vernon Schryver wrote:
> In article <cKKdnSUwt7DwZKfeRVn-ug@rogers.com>,
> James Knott <james.knott@rogers.com> wrote:
>
> >NAT will no longer be necessary, when IPv6 is commonly used. There will be
> >so many addresses available, that everyone can have billions of addresses.
> >In fact, your MAC address will form part of your IP addresses (yes, you
> >will likely have multiple addresses for each computer).
>
> I wish that were true, but it is quite wrong.
>
> NAT will be at least as popular when IPv6 is common as it is now.
> There are still many unallocated IPv4 addresses. The IPv4 addressing
> problem is much less the paltry 4 billion address space than it is the
> size of default free routing tables. By many accounts IPv6 will make
> the routing table size problem worse instead of better, and not IPv6
> addresses are 4 times larger but because of multi-homing.
>
> NAT has always been advertised as a global address shortage solution,
> but actually installed to deal with other issues. Probably the most
> common real reason for using NAT at first was laziness. Assigning and
> tracking blocks of addresses is more work than single addresses. NAT
> really took off as a way to avoid paying consumer-grade ISP prices for
> blocks of static addresses.
>
> Note also that IPv4 DHCP and PPP IPCP are tuned for automatically
> assigning single addresses instead of blocks. Maybe in theory IPv6
> neighbor discovery wouldn't have the same problems, but I wouldn't
> count on that in practice.
>
> Then there is the legacy problem. What is an easier way for a DSL
> or cable-modem ISP to deploy IPv6 than new "modem" firmware that
> uses NAT to connect consumer IPv4 LANs to the ISP's IPv6 network?
>
> NAT is like VHS tape and the automobile, arguably evil but very difficult
> to get rid of once they're popular.
>
>
> (Why follow-up to comp.dcom.lans.ethernet? NAT is more on-topic for
> comp.protocols.tcp-ip than comp.dcom.lans.ethernet.)

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. So, I thought it was likely that thess home routers were only
marketted as routers, so seemed closely related to many threads in that
newsgroup. Turns out they are routers, use a routing protocol.
Anonymous
September 28, 2005 10:00:30 PM

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

Rick Jones wrote:
> In comp.protocols.tcp-ip Patrick Schaaf <mailer-daemon@bof.de> wrote:
> > NAT is NAT.
>
> I thought it went 'NAT is evil' :) 
>
> As I recall it:
>
> *) 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 :) 
>
> *) decices that operate at the network layer (eg IP) are routers
>
> *) devices that operate at the transport layer and higher are gateways
>
> Now, when you create eierlegendwolmilchsau (*), layer-blurring devices
> such as firewalls and NATs you basically toss a grenade into the works
> and knuth only knows what to call it besides "bletch."
>
> rick jones

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

I have read something about gateways connecting NWs of dissimilar
protocols or architectures. But, architecture are layer 1 and 2 too. So
the distinction between router and gateway doesn't seem tobe being able
to operate at the transport layer and application layers.

I haven't even heard of other devices at layer 3 that aren't routers.
And I haven't heard of a router without a routing protocol. (or routing
table).

Is all this addressed in one or several books?

thanks
Anonymous
September 28, 2005 10:32:30 PM

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

In comp.protocols.tcp-ip Patrick Schaaf <mailer-daemon@bof.de> wrote:
> NAT is NAT.

I thought it went 'NAT is evil' :) 

As I recall it:

*) 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 :) 

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

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

Now, when you create eierlegendwolmilchsau (*), layer-blurring devices
such as firewalls and NATs you basically toss a grenade into the works
and knuth only knows what to call it besides "bletch."

rick jones

(*) I've probably butchered the german spelling of egg-laying, wolly,
milk-pig

--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
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...
Anonymous
September 28, 2005 10:37:09 PM

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

In comp.dcom.lans.ethernet Rick Jones <rick.jones2@hp.com> wrote:
> I thought it went 'NAT is evil' :) 

Hardly. NAT is a pseudo-clever way of hooking networks together.
Trade the underutilized ports field for the scarce address field.
Remember, the Internet is not one network, but a network of networks.

> Now, when you create eierlegendwolmilchsau (*), layer-blurring
> devices such as firewalls and NATs you basically toss a grenade
> into the works and knuth only knows what to call it besides "bletch."

No, these little home devices are really gateways.
There is nothing wrong with what they do.

OTOH, some apps may break if they depend on very specific behaviour.
That's OK. IPv4 & TCP/IP is about moving data, not making apps work.
That's for the apps programmers. In particular, just because
a connection can be opened in one direction has never implied a
guarantee that another could be opened in the opposite direction.

-- Robert
Anonymous
September 28, 2005 10:37:10 PM

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

Robert Redelmeier wrote:

> Hardly. NAT is a pseudo-clever way of hooking networks together.
> Trade the underutilized ports field for the scarce address field.
> Remember, the Internet is not one network, but a network of networks.
>

NAT will no longer be necessary, when IPv6 is commonly used. There will be
so many addresses available, that everyone can have billions of addresses.
In fact, your MAC address will form part of your IP addresses (yes, you
will likely have multiple addresses for each computer). It will also
eliminate the need for DHCP, as each device can determine it's own
addresses etc.
Anonymous
September 28, 2005 10:37:11 PM

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

In article <cKKdnSUwt7DwZKfeRVn-ug@rogers.com>,
James Knott <james.knott@rogers.com> wrote:

>NAT will no longer be necessary, when IPv6 is commonly used. There will be
>so many addresses available, that everyone can have billions of addresses.
>In fact, your MAC address will form part of your IP addresses (yes, you
>will likely have multiple addresses for each computer).

I wish that were true, but it is quite wrong.

NAT will be at least as popular when IPv6 is common as it is now.
There are still many unallocated IPv4 addresses. The IPv4 addressing
problem is much less the paltry 4 billion address space than it is the
size of default free routing tables. By many accounts IPv6 will make
the routing table size problem worse instead of better, and not IPv6
addresses are 4 times larger but because of multi-homing.

NAT has always been advertised as a global address shortage solution,
but actually installed to deal with other issues. Probably the most
common real reason for using NAT at first was laziness. Assigning and
tracking blocks of addresses is more work than single addresses. NAT
really took off as a way to avoid paying consumer-grade ISP prices for
blocks of static addresses.

Note also that IPv4 DHCP and PPP IPCP are tuned for automatically
assigning single addresses instead of blocks. Maybe in theory IPv6
neighbor discovery wouldn't have the same problems, but I wouldn't
count on that in practice.

Then there is the legacy problem. What is an easier way for a DSL
or cable-modem ISP to deploy IPv6 than new "modem" firmware that
uses NAT to connect consumer IPv4 LANs to the ISP's IPv6 network?

NAT is like VHS tape and the automobile, arguably evil but very difficult
to get rid of once they're popular.


(Why follow-up to comp.dcom.lans.ethernet? NAT is more on-topic for
comp.protocols.tcp-ip than comp.dcom.lans.ethernet.)


Vernon Schryver vjs@rhyolite.com
Anonymous
September 28, 2005 10:42:21 PM

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

James Knott wrote:

> Robert Redelmeier wrote:
>
>> Hardly. NAT is a pseudo-clever way of hooking networks together.
>> Trade the underutilized ports field for the scarce address field.
>> Remember, the Internet is not one network, but a network of networks.
>>
>
> NAT will no longer be necessary, when IPv6 is commonly used. There will
> be so many addresses available, that everyone can have billions of
> addresses. In fact, your MAC address will form part of your IP addresses
> (yes, you
> will likely have multiple addresses for each computer). It will also
> eliminate the need for DHCP, as each device can determine it's own
> addresses etc.

And of course ISPs will no longer charge for static IPs and for each
additional address. Sure they won't.

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)
Anonymous
September 28, 2005 11:02:24 PM

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

jameshanley39@yahoo.co.uk wrote:
> Wayne wrote:
> > <jameshanley39@yahoo.co.uk> wrote in message
> > news:1127904921.081046.68950@z14g2000cwz.googlegroups.com...
> > >
> > > If there's a routing table, what is in it? (I will speculate)
> > >
> >
> > No need to speculate. Here's a sample routing table from a Linksys
> > broadband router made circa 2000.
> >
> > Destination LAN IP Subnet Mask Default Gateway Hop
> > Count Interface
> > 0.0.0.0 0.0.0.0 64.x.x.x 1 WAN
> > 64.x.x.x 255.255.240.0 0.0.0.0 1 WAN
> > 192.168.10.0 255.255.255.0 0.0.0.0 1 LAN
> >
> > One entry for the ISP's next-hop, one entry for each directly attached
> > network. Simple? Yes. Small? Yes. Still a routing table, still routing
>
> yes, btw, where did you get LinkSys command ref from? (note-I managed
> to find DLink DSL504 here http://shadow.sentry.org/~trev/dsl50x.html)
>
> it's interesting. My DLink DSL504 router actually doesn't list local
> IPs in the routing table. I guess its NAT is implemented in the
> firewall part.
>
> There is only one entry in my router's routing table - that entry being
> the default route.
>
> 192.168.0.1> ip route
> route add ppp_route 0.0.0.0 82.70.237.22 00:00:00:00 1 0 1 #
> MAN via ppp_device
> 192.168.0.1>
>
> so, doesn't seem like much need to look up the dest ip. Doesn't look
> like RIP is doing much.
> If the Dest IP is its own IP, then NAT and PAT kicks in. And if it's
> anything it just goes to the routing table and takes the default route,
> which is out the WAN interface to the ISP's router.
>
> But there are commands and ways in the web interface, to add entries.
> THe web interface mentions 2 interfaces ISP1 and Ethernet (makes
> sense).
>
> I guess if I could disable NAT such that packets could arrive at my
> router with an IP of one of my local computers, - then I could start
> adding entries to the routing table.
>
> though with NAT, and this one WAN interface for the default route
> entry. The whole RIP (that seems to advertise nothing - what subnets
> are connected at my end to my router, that it would advertise? None-
> The one subnet that it has at my end is NATed anyway - not advertised)
> and Routing Table(with the 1 default entry) seems like overkill!
>
> But I guess it's still techically a rouiter, for its RIP and routing
> table.

ah,my mistake. I didn't realise your routing table was - like mine -
as expected - not listing NAT either. You actually have 2 directly
connected networks and they aren't behind NAT. Since they are in the
routing table and the Dest IP could equal an IP on one of those
networks. I didn't have that in mind when I thoguht of a home router.
I have trouble trying to disable NAT on my home router. Your router is
certainly more router like than mine!
Anonymous
September 28, 2005 11:39:02 PM

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

In article <1127953916.755392.135100@g49g2000cwa.googlegroups.com>,
<jameshanley39@yahoo.co.uk> wrote:

>it's interesting. My DLink DSL504 router actually doesn't list local
>IPs in the routing table. I guess its NAT is implemented in the
>firewall part.

What makes you think it is a separate part instead of iptables, ipfw,
or similar?
http://www.linuxdevices.com/links/LK7129786296.html


>I guess if I could disable NAT such that packets could arrive at my
>router with an IP of one of my local computers, - then I could start
>adding entries to the routing table.

It seems to be impossible to disable NAT on many consumer grade boxes.
You can tell them to do nothing, but they still insist on counting SYNs
or other things that mess things up. (E.g. 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.)

All of the boxes I've looked at in recent years let you fiddle with
the routing table regardless of their NAT settings, while some don't
let you even ossensibly turn off NAT.


>though with NAT, and this one WAN interface for the default route
>entry. The whole RIP (that seems to advertise nothing - what subnets
>are connected at my end to my router, that it would advertise? None-

The good reason your box might support RIP is to advertise a default
route to hosts on your home network. For many years RIP has been mostly
a router discovery protocol, as well as by far the most popular router
discovery protocol. See
http://www.google.com/search?q=router+discovery+protoco...


Vernon Schryver vjs@rhyolite.com
Anonymous
September 29, 2005 1:06:35 AM

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

J. Clarke wrote:

>> NAT will no longer be necessary, when IPv6 is commonly used. There will
>> be so many addresses available, that everyone can have billions of
>> addresses. In fact, your MAC address will form part of your IP addresses
>> (yes, you
>> will likely have multiple addresses for each computer). It will also
>> eliminate the need for DHCP, as each device can determine it's own
>> addresses etc.
>
> And of course ISPs will no longer charge for static IPs and for each
> additional address. Sure they won't.

According to what I've read, they won't be able to give out individual
addresses. Instead, customers get a fairly large block (at least 48 bits),
because the last 48 bits of your IP address are the same as your MAC
address. This means that no more than 80 bits can be assigned by the ISP,
to a subscriber.
Anonymous
September 29, 2005 1:31:54 AM

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

In comp.dcom.lans.ethernet James Knott <james.knott@rogers.com> wrote:
> NAT will no longer be necessary, when IPv6 is commonly used.

Entirely true. I will mourn the passing of IPv4 and the weak
anonymity that DHCP provides. The Internet will change.

I'm not sure the IPv6 will be adopted so very quickly.
All new routing hardware will be required and the overhead
of 128bit addresses, QoS et al is approx 10% more than IPv4.

-- Robert
Anonymous
September 29, 2005 1:31:55 AM

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

Robert Redelmeier wrote:

> In comp.dcom.lans.ethernet James Knott <james.knott@rogers.com> wrote:
>> NAT will no longer be necessary, when IPv6 is commonly used.
>
> Entirely true. I will mourn the passing of IPv4 and the weak
> anonymity that DHCP provides. The Internet will change.
>
> I'm not sure the IPv6 will be adopted so very quickly.
> All new routing hardware will be required and the overhead
> of 128bit addresses, QoS et al is approx 10% more than IPv4.

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. 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.
Anonymous
September 29, 2005 4:50:00 AM

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

James Knott wrote:

> J. Clarke wrote:
>
>>> NAT will no longer be necessary, when IPv6 is commonly used. There will
>>> be so many addresses available, that everyone can have billions of
>>> addresses. In fact, your MAC address will form part of your IP addresses
>>> (yes, you
>>> will likely have multiple addresses for each computer). It will also
>>> eliminate the need for DHCP, as each device can determine it's own
>>> addresses etc.
>>
>> And of course ISPs will no longer charge for static IPs and for each
>> additional address. Sure they won't.
>
> According to what I've read, they won't be able to give out individual
> addresses. Instead, customers get a fairly large block (at least 48
> bits), because the last 48 bits of your IP address are the same as your
> MAC
> address. This means that no more than 80 bits can be assigned by the ISP,
> to a subscriber.

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?

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)
Anonymous
September 29, 2005 5:12:08 AM

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

In comp.dcom.lans.ethernet jameshanley39@yahoo.co.uk wrote:
> Doesn't look like RIP is doing much.

FWIW, doesn't have to have RIP, or any routing protocol for that
matter, to be a router.

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...
Anonymous
September 29, 2005 5:42:56 AM

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

In comp.protocols.tcp-ip jameshanley39@yahoo.co.uk wrote:
> Rick Jones wrote:
>> In comp.protocols.tcp-ip Patrick Schaaf <mailer-daemon@bof.de> wrote:
>> > NAT is NAT.
>>
>> I thought it went 'NAT is evil' :) 
>>
>> As I recall it:
>>
>> *) 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 :) 
>>
>> *) decices that operate at the network layer (eg IP) are routers
>>
>> *) devices that operate at the transport layer and higher are gateways
>>
>> Now, when you create eierlegendwolmilchsau (*), layer-blurring devices
>> such as firewalls and NATs you basically toss a grenade into the works
>> and knuth only knows what to call it besides "bletch."
>>
>> rick jones

> 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, or maybe something from CS244 (?)
when I was still entertaining notions of getting an MS via SITN. (I
decided to stick with my BS :) 

Maybe one of the Stevens or Stallings books.

> I haven't even heard of other devices at layer 3 that aren't
> routers. And I haven't heard of a router without a routing
> protocol. (or routing table).

All a routing protocol does is stuff things into the routing table.
One does not have to have a routing protocol going to have a "thing"
be a router.

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...
Anonymous
September 29, 2005 5:42:57 AM

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

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.


Vernon Schryver vjs@rhyolite.com
Anonymous
September 29, 2005 5:46:36 AM

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...
Anonymous
September 29, 2005 6:57:50 AM

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
Anonymous
September 29, 2005 9:54:30 AM

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
Anonymous
September 29, 2005 10:02:19 AM

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?
Anonymous
September 29, 2005 10:35:03 AM

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,
Anonymous
September 29, 2005 11:49:08 AM

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.
Anonymous
September 29, 2005 11:51:39 AM

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.
Anonymous
September 29, 2005 11:53:50 AM

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.
Anonymous
September 29, 2005 1:33:53 PM

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)
Anonymous
September 29, 2005 3:59:38 PM

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.
Anonymous
September 29, 2005 4:14:15 PM

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.
Anonymous
September 29, 2005 6:37:34 PM

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
Anonymous
September 29, 2005 6:37:35 PM

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.
Anonymous
September 29, 2005 6:45:29 PM

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
>
Anonymous
September 29, 2005 6:45:30 PM

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.
Anonymous
September 29, 2005 9:56:39 PM

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...
Anonymous
September 29, 2005 9:58:54 PM

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...
Anonymous
September 29, 2005 10:02:29 PM

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...
Anonymous
September 29, 2005 10:47:59 PM

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
Anonymous
September 30, 2005 1:40:31 AM

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