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

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
44 answers Last reply
More about device home router router
  1. 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!!!
  2. 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
  3. 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
  4. 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.
  5. 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
  6. 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.
  7. 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
    >
  8. 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.
  9. 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.
  10. 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
  11. 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...
  12. 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
  13. 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.
  14. 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
  15. 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)
  16. 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!
  17. 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+protocol


    Vernon Schryver vjs@rhyolite.com
  18. 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.
  19. 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
  20. 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.
  21. 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)
  22. 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...
  23. 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...
  24. 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
  25. 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...
  26. 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
  27. 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
  28. 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?
  29. 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,
  30. 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.
  31. 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.
  32. 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.
  33. 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)
  34. 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.
  35. 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.
  36. 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
  37. 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.
  38. 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
    >
  39. 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.
  40. 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...
  41. 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...
  42. 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...
  43. 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
  44. 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...
Ask a new question

Read More

Routers Internet Service Providers Devices Networking