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