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

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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.

 

[Guest]

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

 

[Guest]

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.

 

[Guest]

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
>

 

[Guest]

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.

 

[Guest]

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.

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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.

 

[Guest]

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

 

[Guest]

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)

 

[Guest]

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!

 

[Guest]

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

 

[Guest]

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.

 

[Guest]

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

 

[Guest]

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.

 

[Guest]

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)

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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