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

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

On 04/02/2019 13:54, Ole Troan wrote:> “real life looks like”… Why 
wouldn’t it? If the ISP has a routed
> interface directly towards the customer, then having a fixed /56 PD
> configured on that customer facing interface, that sure looks like
> real life to me. Or a fixed mapping of remote-id to a /56 in a DHCP
> PD database…

This is rarely a real life scenario. More common is a PPPoE or one of 
the derivatives, where you create a virtual layer over the physical 
layer and the other endpoint can be terminated wherever ISP feels like 
on this particular day. Moving people around BRAS-es is not uncommon.

However, I always advocated ISPs to put static IPv6 PDs in Radius (or 
whichever AAA mechanism they use), so that the same user always gets the 
same PD.

This approach is good until you have a requirement to do multiple PPPoE 
sessions per username. Then things get messy and that's the reason why 
people think of dynamic PDs ;)

My suggestion is to have separate dynamic /64 prefixes to number the WAN 
link (it works for multiple PPPoE sessions and also it gives IPv6 access 
to a very simple PPPoE client that doesn't do a PD request, like 
end-host machine with Windows or something) and fixed PD that just the 
first PPPoE session is able to get. This usually covers most of the 
scenarios. For the corner cases then ISP needs to solve them case by 
case, but at least for majority of clients that's the solution.

> 
> Sure, there are ISPs that use DHCP PD servers that allocate from
> pools. But I have a hard time seeing why that should be easier,
> cheaper, more managable than a static mapping table.

ISPs actually thinks that.

<sarcasm>
It's easy to deploy, it works in lab scenario, dynamic worked for IPv4 
and hey, users will never notice it as in case of issues they fall-over 
to IPv4 anyway ;) #happyEyeballsToTheRescue
</sarcasm>

> 
> (and don’t get me wrong, I’m all in favour of making CPEs and hosts
> more robust. I’m just trying to emphasize the point, that you can
> hardly blame the CPEs not working well, in a network that’s by some
> definition misconfigured. 

It is misconfigured :) But stuff happens without you wanting it to 
happen and then you need the edge to react properly.

<analogy>
It's the same as if you would be walking down the street and all of a 
sudden there is a gunfire around you. Now you have two options:
- react and hide from the bullets
- continue walking, saying that this street was not supposed to be under 
fire, city is not treating you well and there were no bullets flying 
around a minute ago.
</analogy>

Now you pick what you would do ;)

I personally would react to the new situation regardless of what I think 
the situation would have to look like - and so I think that CPEs and 
end-hosts needs some mechanism to adopt if things go wrong...

> I am still on the fence if the way to
> achieve that is through an IETF document or something else though).

Any idea of what something else could be? IETF could be the right place 
to address that...

Cheers and thnx, Jan