Re: [v6ops] Implementation Status of PREF64

[Philip Homburg <[e-mail]>]

>> The net effect is that new flows use the new prefix right away, but the old
>> prefix can be used for 2 hours longer. So timers are limited to 2 hours.
>
>Indeed, this can be done with SLAAC.

I responded to Owen, who was arguing that DHCP is better suited to deal
with flash renumbering than SLAAC.

>deploying SoHo networks where ISPs tend to change prefixes every now
>and then, but managed enterprise networks.  Prefixes change when the
>admin says so, and they know how to deal with DHCP lease timers, 
>change prefixes at times when nobody is at work, and so on.

Indeed. 

>(Now: supporting a DHCPv6 *server* on an Android device running as
>mobile hotspot with frequently changing uplink connectivity - here I
>totally agree that DHCPv6 is not the right tool for such a network
>setup.  But nobody is asking for it, and refusing DHCPv6 client support
>because DHCPv6 server support on the same device is not a useful
>thing sounds a bit... "painted myself into a corner" -ish)

The impression I got was that the main reason to refuse to implement
DHCPv6 IA_NA on Android is to always have a sufficiently large number
of addresses available. With SLAAC you just pick what you want from a
/64. Which DHCPv6 you might be limited to one address.

The argument strikes me as odd, because a router or a switch can limit a 
device to just a few (or one) IP address. And I have encoutered such
devices often enough to know that it is not just a theoretical concept.