Re: slaac-renum: New rev of draft-gont-6man-slaac-renum (Fwd: New Version Notification for draft-gont-6man-slaac-renum-08.txt)

[Philip Homburg <[e-mail]>]

>> My issue is with LTA_DEPRECATE.
>
>What's the issue with LTA_DEPRECATE when the algorithm separates the 
>processing of different address types (e.g. ULA and NON-ULA)?

I'm saying it is fragile, because it will fail if a third type of address
is in use.

>Note: Previous alternative proposals have suggested to prefer the latest 
>prefix received, in which case, if prefixes were sent in multiple RAs or 
>there were multiple-prefixes sent by multiple routers, they were 
>guaranteed to oscilate.

This sounds like a strawman. You ignore my proposal and then refer to something
that has been shot down already.

>> This means that valid reasons can exist why the router doesn't do that.
>
>SHOULD is "only do if you have a very good reason". And, if for some 
>reason you were to send PIOs in different RAs, non-ulas are only 
>deprecated by non-ulas, and ula-are only deprecated by ulas. (assumming 
>PIOs are sent in multiple RAs (currently not the case, there are 
>multiple non-ulas pios being sent (not the typical case, either) *and* 
>an RA gets lost).
>
>Where's the breakage?

Packets gets lost all the time. It is very fragile if we have one part
of a standard that says that you can split RAs and then another where hosts
will fail in unexpected ways if you do that. In my book that's just a bad
standard.

If you want it to be a MUST then make it a MUST and see if that gets 
consensus.

If you keep it at a SHOULD because the MUST doesn't get consensus, then
take it into account that RAs will be split.

>The document does consider it -- that's why prefixes are not deprecated 
>at once. Deprecation will only happen if there's another address of the 
>same type being announced.

Like I said many times already, that will fail if there a 3rd type of address.

>> Can you give an example. In thinking about the current problem, I found the
>> policy table remarkably ineffective when it comes to ULAs.
>
>See the rule about addresses of minumum scope. Otherwise you'd never get 
>to actually use ULAs.

ULAs get picked up by the longest matching rule. Maybe you can give
an example where a ULA doesn't get using the old table?

>> I can imagine an issue with destination selection if you have both a ULA and
>> a non-ULA as part of a single DNS RR-set.
>
>Which issue?

Upon re-reading RFC 3484 it seems that destination selection would also
work if the host has no knowledge of ULAs.

>non-ULAs are only deprecated when you have another non-ula. Same with 
>ULAs: you only deprecate an ULA if you have another preferred ULA.
>
>THe algorithm in draft-gont-6man-slaac-renum will never deprecate the 
>only ULA you ahve or the only non-ula you have.

This fails if there is a 3rd type of address.

>That's because strictly speaking is not a different address type: they 
>are essentially  GUAs that are known to be filtered on the site boundary.

That's why it is fragile to have an algorithm that can fail if there is
a third type of global address.

>If you introduce a new address type, yes, of course you need hosts to be 
>updated. There's no magic.

I explained before that ULAs can be used by hosts that have an unmodified
policy table, just like RFC 1918 addresses are used by unmodified IPv4 hosts.

So, yes there is magic. Hosts do not have to know about the properties of
the routing system.

>You seem to assume that:
>1) You can positively tell whether a router splits RAs -- but you can't. 
>You're still playing with probabilities here.

I'm just assuming the same packet loss as for RAs in general.

>2) This requires more complexity, and more packets (multiply that by 
>number of hosts in a network).

It doesn't require more packets. It may take a host longer to deprecate a 
prefix in rare circumstances.

>3) And all this to deal with a case that this document recommends 
>against, does not currently happen in practice, and that is dealt with 
>the current algorithm, as indicated above.

Then make it a MUST. Keeping it a SHOULD is a clear indication that the
split will happen.

If you say: a router MUST send all SLAAC prefixes in a single RA,
then this problem is solved.