Where to buy Internet IP addresses
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