On 2/3/2011 6:03 PM, Mark Andrews wrote:
The protocol was done in December 2003. Any CPE vendor could have added support anytime in the last 7 years. Did we really need to specify how to daisy chain PD requests when these vendors have been daisy chaining DHCPv4 for various option without any written specification?
NAT definitely made it easier. The same can't be said for DHCPv6-PD. And yes, replacing NAT with a protocol that will handle dissemination of network prefixes deserved having a standards based formula. For CPEs to work well, there must be expectations of what will happen in a number of scenarios so that they can deal with it. For example, will the CPE just hand out /64 networks behind it to other routers? Will it hand out a prefix one longer than what it received and increment up until it's out of space? How does this work in the myriad of ways home users connect things? Cheap CPE routers have come a long way over the last decade. They are probably as close to perfect as you can expect for the price. Now we're just starting over to go through the pains of trying to automate home routers.
Seriously. CPE vendors could have release IPv6 capable products that had a stateful firewall, DHCPv6 with prefix delegation 7 years ago. There was *nothing* stopping them except themselves.
People have been retrofitting CPE devices to have this functionality for about as long as this.
Prefix delegation replaces NAT, but there's no standard for how to divide it up? Sure, people have retrofit it for years. I have myself. However, even in linux, it's a very manual process and involves deciding for yourself how you will hand out prefixes behind the front router. This wasn't a concern with NAT. The most NAT had to worry about was conflicting addresses on the LAN/WAN (and most, these days, will auto renumber if necessary). Jack