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

[Fernando Gont <[e-mail]>]

On 28/5/20 08:24, Philip Homburg wrote:
>>> I'm saying it is fragile, because it will fail if a third type of address
>>> is in use.
>>
>> That's an overstatement. Firstly, it's impossible to tell what may be
>> specified in the future, and how (whatever is specified) may work with
>> existing standards. For example, it is impossible to tell how a new
>> address type may work (or break) with source address selection (RFC6724).
>>
>> Unless you can't predict the future, you can't say "it will fail"
>> (modulo the fact that, failing requires a bunch of other conditions).
> 
> I described how ULAs essentially require no host changes (i.e., it would
> work fine with the old policy table). I can think if one corner case where
> the policy table would make a difference.

The current SAS spec is RFC6724.

ULAs are handled by a policy table, that essentially also enforces rules 
based on "cope" (besides the explicit rule #2). ULAs are explicitly 
coded in the policy table.



> So to be specific, I expect that in the future, some organisations with
> either use public IPv6 address as if they were ULAs, or use two different
> ULA prefixes for different perposes.

While possible, that doesn't seem in-line with RFC4193. And depending on 
how you do it, it may certainly break (e.g, site uses multiple ula 
prefixes, and none of them are reachable with the others.. so when a 
node selects ULAs as a dst/src address involving different prefixes, 
communications just fail).




> These two use cases can be analysed in the context of your proposal.
> 
>>> 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.
>>
>> This document says "SHOULD NOT". That means "don't, unless you really
>> know what you are doing".
> 
> This is why I call it fragile. We have SHOULD NOT, and then operators have
> to be aware of obscure corner cases of host behavior to evaluate the
> SHOULD NOT.

There's no obscure cases. An unless you're advertising 1000 SLAAC 
prefixes via RAs, you don't have a valid reason to split the PIOs among RAs.

Note: the same document saying "SHOULD NOT" is the same document that 
specifies the algorithm. So a folk that just happens to go against the 
SHOULD NOT, with no reason, and without reading the document is simply 
not doing due diligence.



>> We have kept it as "SHOULD" because it doesn't warrant a MUST. As noted:
>> worst case scenario you unprefer an address.
> 
> Which as I described before, in the case an organisation has three different
> type of addresses will lead to failure. So it is not a benign as you make
> it out to be.

As noted above: if one ever went to specify another address type, nodes, 
most likely, need to be made aware about them in a lot of places (as 
shown for source address selection).

You can't claim that an algorithm is fragile to something that doesn't 
exist, and that you don't even know if it will ever exist -- besides the 
fact that, as noted, the stack needs to be aware about the address type, 
to do whatever special processing is intended.



>> Please see the rules in RFC6724: "longest match" is Rule #8 -- the
>> *last* one. And it is Rule #2 (which needs to be ULA-aware) that
>> guarantees that ULA will be used for ULA.
>>
>> So your statement is certainly incorrect.
> 
> Rule #2 says 'Prefer appropriate scope', however ULAs have global scope
> (see Section 3.1). So it is not clear to me what you are try to say here.

Yup, my bad. But the same holds true: ULAs are *not* handled by 
longest-prefix match. The policy table is employed by Rule #6 of SAS, 
which comes before Rule #8 (longest matching prefix). i.e., use of ULAs 
for the source addresse is *not* taken care by the longest-matching 
prefix rule.

Without Rule #6, a node that employs temporary addresses for GUAs but 
not for ULAs (what you'd probably want to do in most scenarios) would 
prefer GUAs when communicating with a ULAs (via Rule #7).

It should be clear that address types are well intertwined in source and 
destination address selection. The policy table makes it quite evident 
that address types are pretty well hard coded.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492