DComTalk.com

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

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

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

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

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

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

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

Patrick Schaaf wrote:

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

Actually, it's ethernet frames and IP datagrams.

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

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

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

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.

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,
since by then all bridges were "multi-port." The slight taint of
technical substance was that "switches" could look at first 12 bytes
of payload before starting to forward the frame, with the disadvantage
of forwarding CSMA/CD fragments. Another characteristic was a lack
of (an equivalent to) spanning-tree so that if you weren't careful,
you could create loops and packet storms. (Recall Kalpana.) It wasn't
long before "switch" was broadened to cover anything thing that shuffles
data "fast," just as toothpaste "makes your smile brighter," and never
mind asking "faster" or "brighter than what?" The suckers were supposed
to understand "switch" as meaning "ASIC" or something else that told
them nothing they (or the marketoons blathering it) could understand
except "Buy Me Now And You'll Look Smart!"

Today everything is a "switch." Everything or close to everything is
both a bridge and a router. What modern packet forwarding box can't
be taught to forward (and filter) based on link layer addresses, IP
addresses, or both at once?

Even the router salescritters have stopped beating their old shibboleth
of a distinction between hosts and routers, what with all routers
supporting "host protocols" like syslog, telnet, ssh, and http and all
hosts supporting all routing protocols. Cisco's IOS has grown so
elaborate and has so many security advisories that not even Cisco
salescritters can say it's simpler than a "host" operating system.
Many other vendors run various, largely unvarnished UNIX-like operating
systems such as FreeBSD, NetBSD, and Linux, including plenty of cheap
consumer grade cable and DSL modems. You might be surprised by how
many of them answer port 22 or 23 with familiar banners; I was.

Turns out they are routers, use a routing protocol.

According to my rule book, an IP router is anything that forwards IP
packets with or without a routing protocol. How it decides where to
forward is irrelevant. A gateway, IP packet forwarder, or whatever
you call it with a static table is as much a router as some other box
that that uses an IGP or EGP or random caprice--not that there is
always much difference.


Vernon Schryver vjs@rhyolite.com

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+d ... y+protocol


Vernon Schryver vjs@rhyolite.com

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