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

[Jan Zorz - Go6 <[e-mail]>]

On 18/02/2019 19:32, Lee Howard wrote:
> 
> 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 was thinking about that. ;)

> 
> 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.

You did. But RIPE-690 was all about documenting current reality of 
operational environments and practices that can work today and not about 
the future where we want to go.

Shaping the future where we want to go is taking place with this I-D and 
now it's time to say how we want the deployment of IPv6 protocol at 
various network (end)points to be done.

> 
> 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

Making end-host more robust doesn't hurt. Giving a good advice on how to 
build a CPE to be nicer towards the host doesn't hurt. Mandating 
operators to honour the lifetime of PD that they set themself and not 
change prefix before expiry (if there is no emergency situation in the 
network) would also help.

> 
> 
>>
>> - 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.

My immediate reaction would be "as far on the edge as possible" :)

> 
> 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.

I believe that proposed change in ND in this I-D would do the job. But 
I'm obviously biased ;)

Cheers and thnx, Jan

> 
> Lee
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------