Re: A common problem with SLAAC in "renumbering" scenarios

[Alexandre Petrescu <[e-mail]>]

Le 18/02/2019 à 19:32, Lee Howard a écrit :
> 
> On 2/15/19 4:20 PM, Sander Steffann wrote:
>> Hi Lee,
>>
>>> Seems to me several operators have offered their opinions here. If 
>>> you want more opinions, maybe ask a group of operators?
>> Not a very helpful comment... I think the underlying problem here is 
>> that there is no technical solution available that solves stable IPv6 
>> address delegation at residential scale in an acceptable way.
> 
> The question was, "Would operators support this solution?" To that 
> question, asking a group of operators seems to me to be a pretty sound 
> suggestion.

I think it is very relevant to ask at least one operator whether 
DHCPv6-PD gives a stable prefix to a home or mobile user.

Alex

> 
> I disagree that the problem to be solved is "stable IPv6 address 
> delegation," and said so repeatedly and loudly when we worked on 
> RIPE-690, along with the only other large operator involved in editing 
> that document.
> 
> The problem to be solved is stale address state. Stable prefix 
> delegation would be one solution. Better dynamic renumbering would be 
> another, which could be handled in ways Fernando describes in his draft 
> (draft-gont-6man-slaac-renum-00 in case anyone's forgotten), or several 
> others
> 
> 
>>
>> - For stable address delegation the routing inside the ISP becomes a 
>> mess, especially when it can't be guaranteed that a customer 
>> consistently ends up at the same BNG.
>> - To keep ISP networks scalable, prefixes are aggregated to (roughly) 
>> BNG level, making it impossible to keep prefix delegation stable at 
>> the customer's end
>>
>> With IPv4 this didn't cause massive problems because NAT disconnected 
>> the LAN addresses from the WAN side at the customer's end. With IPv6 
>> this is no longer the case and it does cause problems.
>>
>> Stability at one end causes instability at the other end, and vice versa.
>> And as can be seen from this discussion it's still an unsolved problem...
> 
> That's a good summary. Similar to Nick Hilliard's description of where 
> the network state information lives.
> 
> We can try to solve this with locator-ID splits, but that solution space 
> has been sitting around for a while, and I'm not sure it ultimately 
> solves the problem. We can always add a layer of indirection (put a 
> mapping somewhere) but it doesn't help the stub hosts.
> 
> Lee
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>