Re: quietly....

[Jack Bates <jbates () brightok net>]

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