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

[Lee Howard <[e-mail]>]

Before I plonk this thread. . .

On 2/5/19 10:44 AM, Jan Zorz - Go6 wrote:
> On 05/02/2019 13:10, Philip Homburg wrote:
>>> The problem starts when the ISP wants to change prefixes.
>>>
>>> How often will they really need to do that?
>>>
>>> I think a lot of this need in IPv4 has come from IPv4 addresses being
>>> precious and expensive resources. Consequently, it has been worth the
>>> expense and effort of fine grained management of them.
>>>
>>> In IPv6, that level of management isn't needed. Addresses are 
>>> plentiful and
>>> cheap, so you can throw lots of address space at problems.
>>
>> Ideally every customer just gets a static /48. There is no technical 
>> reason
>> why this can't be made to work.
>
> Agreed 100% :)


I cordially invite you to go build your own network, so you will 
actually be able to tell somebody how to build their network.


>
>>
>> Reality is that ISPs have lots of reasons to do things differently. I 
>> don't
>> think we are in position to tell ISPs that they are doing it wrong. 
>
> Hmm. We could be in a position to tell them they are doing it wrong - 
> if they are doing it wrong :) And clearly - they are doing it wrong, 
> otherwise things would work and we would not have this conversation ;)
>
> We need to make sure operators stop cutting corners and dragging bad 
> practices from IPv4 into IPv6 world and things will get better.

I checked the charter for 6man, and that is out of scope.

The 6man working group is responsible for the maintenance, upkeep, and
advancement of the IPv6 protocol specifications and addressing
architecture. It is not chartered to develop major changes or additions
to the IPv6 specifications. The working group will address protocol
limitations/issues discovered during deployment and operation.  It will
also serve as a venue for discussing the proper location for working on
IPv6-related issues within the IETF.

6man is the design authority for extensions and modifications to the
IPv6 protocol.  The working group may, at its discretion, review any
document produced in another working group that extends or modifies the
IPv6 protocol and, in consultation with the responsible ADs of both
working groups, may recommend to the IESG that 6man working group
consensus is needed before any of those documents can progress for
publication.


To be thorough, I also checked the charter of v6ops:


1. Solicit input from network operators and users to identify
operational issues with IPv6 networks, and determine solutions or
workarounds to those issues.

2. Solicit input from network operators and users to identify
operational interaction issues with the IPv4 networks, and determine
solutions or workarounds to those issues.

3. Solicit discussion and documentation of the issues and opportunities
in IPv6-only operation, and of the resulting innovations.

4. Operational solutions for identified issues should be developed in
v6ops and documented in informational or BCP drafts.

5. Document operational requirements for IPv6 networks.

These documents should document IPv6 operational experience, including
interactions with IPv4, in dual stack networks, IPv6 networks with IPv4
delivered as an overlay or translation service, or IPv6-only networks.

[continued]


"Telling operators they're doing it wrong" is out of scope for the IETF.



>
>> Reality
>> is also that in lots of markets there is little competition. So if an 
>> ISP
>> does something weird, customers are stuck with it.
>
> We need to fix this before people start pulling IPv4 out of their 
> networks. Today we have another protocol that saves our day if things 
> goes wrong, but when IPv4 is out of our backbones and access networks 
> - all this little failures will show much more prominently.


The right answer is not to make prevent addresses from changing, but to 
make changing painless. Otherwise we are locked into a permanent 
topology, and that is not resilient, it's brittle and doesn't scale.

Unfortunately, no one is paying me to re-open the 6renum working group. 
I regret closing it. Maybe others can do this work.


>
> Cheers, Jan
>
>