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

Hello, Philip,

On 25/5/20 12:16, Philip Homburg wrote:
> [note, I'm replying to multiple messages]
> 
>> That wouldn't be the case. We're talking about:
>>
>> 1) Current algorithm as specified in the I-D, which separates processing
>> of ULA and non-ULA.
>> 2) LTA_INVALID set to, say, "Router Lifetime"
>>
>> Would that address your concern?
> 
> 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)?

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.


>> FWIW, Section "4.4.  Conveying Information in Router Advertisement (RA)
>> Messages" of the draft recommends all PIOs in the same RA.
> 
> I quote "SHOULD include all options"
> 
> 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?


> In addition any router designed before this will be published, only has a
> "MAY".
> 
> So we should seriously consider that case that it is 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.


> Even if you were to make it a MUST, existing routers are still built according
> to MAY.

Well, that's always the case with standards. That said, it has been 
reported that existing routers do not behave that way. So, if anything, 
that's a theoretical case of legacy implementations that doesn't 
actually happen in practice.




>>> When ULAs were introduced, it was transparent to hosts. I know that
>>> they now appear in address selection policy, but nothing will break if they
>>> are not in the policy table.
>>
>> Is that true in the general case? I've certainly written code that
>> would need to be different if there were no ULA rules in the RFC6724
>> policy table.
> 
> 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.



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





>>> When ULAs were introduced, it was transparent to hosts. I know that
>>> they now appear in address selection policy, but nothing will break if they
>>> are not in the policy table.
>>
>> This seems to be at odds with your previous comment. Namely, if
>> they are not in the policy-table, you may end up using ULAs for
>> trying to communicate with globally-reachable addresses -- and as
>> a result communications will likely fail.
> 
> For source address selection, the longest match does the right thing. If
> the destination is non-ULA, then a non-ULA source address is a better match.
> 
> However, if the non-ULA local address is depricated, then the ULA will win,
> and communication will fail.

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.



>> Indeed, I'd argue that in order to make the best out of IPv6
>> addressing the host needs to be aware about the different address
>> types. And an API sitting in between the apps and the lower layers
>> should, to.
> 
> Hosts work just fine without knowing the difference between ULA and non-ULA.
> Host do need to know about link local, and in the past, site local was also
> a big issue. But ULA is quite transparent.

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.



> This is similar to RFC 1918. That was introduced with no changes to hosts, and
> even today, there is very little a host would have to know about RFC 1918.

That's because in IPv4 you typically only configure one address per 
node. If you were configuring both RFC1918 and ipv4-GUAs, and you were 
not using NATs, then you'd experience trouble.



>> When it comes to draft-gont-6man-slaac-renum, one may always make
>> the distinction indirectly. e.g., rather than hardcode ULA/non-ULA
>> in the document, specify the handling for "each address type", and
>> indirectly specify the "address types" as concerned by this document.
> 
> Yes, I'm sure we can refer to the policy table. I guess in practice this
> would an operational headache. How do you ensure that every host in your
> network has an updated policy table.

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



> Especially where there is a split between
> the network admins and support for hosts.
> 
> I don't see why such complexity is better than just checking if a router sends
> all information in a single RA.

The current algorithm does not have such complexity. It is quite simple, 
indeed.

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.

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

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.

That said, I wouldn't mind adding a note that this has been raised, for 
the group to give your algorithm a thought.

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