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

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.

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

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?

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

rick jones

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.

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

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

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

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

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.

QoS? Isn't that equivalent to "drop if congested"? :)

-- Robert

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

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?

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,

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.

No, it refers to various priorities, as determined by the app.

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.

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

Supposed to according to who? It being in a standard won't prevent them if they think it will make them a buck.

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.

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.

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.

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.

What "failure"? If you mean that everybody hasn't rushed out and gotten an HD receiver, why should they if they don't want HD?

Well, actually it's convenience and production cost. DVDs you can press in one shot, tapes have to be recorded one bit a a time. And DVDs don't wear out. DVD looks pretty crappy next to ATSC by the way.