Where to buy Internet IP addresses

Jack Bates jbates at brightok.net
Mon May 4 09:10:08 CDT 2009

Joe Greco wrote:
> How is it the ISP's router is able to handle this?  Be specific.

The primary benefit of chaining is to allocate the correct network 
length to a router. We are not just talking from the ISP to the 
customer, but from the customer's CPE out to other routers. I believe 
chaining also needs support for network length memory (ie, hey, I've 
been handing out 18 networks, so a /59 is my aggregate I should ask 
for), and of course, network length negotiation for PD.

> Now explain why that can't be made to work at the CPE level.

If the ISP hands out a /56, the CPE will still need support for 
chaining. All devices from the ISP out to the furthest customer daisy 
chained router would need support for it. Anything else requires manual 
configuration which is beyond some people's capabilities. If someone 
wants to daisy chain 4 routers serially, with 2 subnets per router off a 
routing CPE, then even if the ISP hands out a /56, each of those routers 
needs to support chaining PD requests and ideally support only 
requesting exactly what they need. So:

ISP -> CPE router /56 -> Linksys1 /61 -> Linksys2 /62 & /63 -> Linksys3 
/62 -> Linksys4 /63

This is without the ISP participating in the chaining since they are 
automatically assigning a /56. However, with negotiation in place, an 
ISP could set a cap on network length (/56 or /48 as they may see fit) 
and can participate in chaining. So customer starts out with a /64, adds 
a router than supports 4 networks and the ISP switches them to at least 
a /61, possibly even just issuing a renumber, reclaiming the original 
/64. It would also be possible to define boundary caps in addition to 
upper caps in negotiation. ie, if you only want a /64, we give that to 
you. If you want a /62, perhaps a /60 is handed out instead. This is 
probably more useful for the ISP than it is CPE side, as the CPE has no 
idea up front how much they can obtain and wasting networks downstream 
through the home network could cause them to run out of assignment space.

In addition, most home network equipment should be able to support 
individual /64 chained PD's without that much trouble given their 
smaller routing tables. So a chained PD request for /64's across home 
networks might work. however, How's a home router supposed to know it's 
actually chaining in the home and not talking to an ISP? So whatever we 
did, it would have to be somewhat generic to support both topologies. Or 
the protocols need to also support flags to define "Hey! I'm an ISP!" 
Which actually isn't a bad idea. See below.

> One of the goals of providing larger address spaces was to reduce (and
> hopefully eliminate) the need to burn forwarding table entries where
> doing so isn't strictly necessary.  When we forget this, it leads us
> to the same sorts of disasters that we currently have in v4.

I agree. That being said, if I presume one table entry per customer, it 
doesn't matter if that entry is a /64, /60, or a /56. Unfortunately, 
DHCPv6 itself doesn't seem to support dynamic length negotiation at this 
time, or chaining requests for supporting the automatic numbering of an 
entire home network with 5+ routers connected however the user wanted to 
connect them, perhaps completely inefficient and with routing loops.

To work properly, this will have to be standardized, or home router 
implementations won't handle clueless home networking very well in a 
number of configurations. It may be useful to treat PD or some other 
protocol that handles the numbering, routing, and loop detection 
differently for home based networks where there is a presumption that 
just plugging something in should work without any knowledge of what 
happens inside the device.


More information about the NANOG mailing list