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

From: Fernando Gont <[email-masked]>
Date: Tue, 19 May 2020 03:38:18 -0300

Folks,

We have posted a revision of draft-gont-6man-slaac-renum. It is 
available at: 
https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-08.txt

The main changes incorporated in this version are:

* We have eliminated the counter-based algorithm from Section 4.5

Previous revisions of the draft contained two alternative algorithms in 
Section 4.5: a counter-based algorithm, and a timer-based algorithm. The 
timer-based algorithm is more robust and simple, so it didn't make sense 
to keep the counter-based algorithm. (Kudos to Philip Homburg for 
"pushing" us to improve the algorithm).

* Clarified the terminology used in the document

This is a rather minor detail. We simply have spelled out that 
throughout the document, "GUAs" refer to "globally reachable" addresses 
(as opposed to ULAs).

The diff from the last rev is available at: 
https://tools.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-08.txt

As always, your feedback will be appreciated.

Thanks!

Cheers,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-6man-slaac-renum-08.txt
Date: Mon, 18 May 2020 23:25:39 -0700
From: [email-masked]
To: Richard Patterson <[email-masked]>, Jan Zorz <[email-masked]>, 
Fernando Gont <[email-masked]>

A new version of I-D, draft-gont-6man-slaac-renum-08.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-slaac-renum
Revision:	08
Title:		Improving the Robustness of Stateless Address Autoconfiguration 
(SLAAC) to Flash Renumbering Events
Document date:	2020-05-18
Group:		Individual Submission
Pages:		24
URL: 
https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-08.txt
Status: 
https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
Htmlized:       https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-08

Abstract:
    In renumbering scenarios where an IPv6 prefix suddenly becomes
    invalid, hosts on the local network will continue using stale
    prefixes for an unacceptably long period of time, thus resulting in
    connectivity problems.  This document improves the reaction of IPv6
    Stateless Address Autoconfiguration to such renumbering scenarios.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Philip Homburg <[email-masked]>
Date: Tue, 19 May 2020 17:24:33 +0200

>https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-08.txt

I disagree with Section 4.1.2. Host should not try to second-guess routers.
So host should keep preferred and valid lifetimes unchanged.

In Section 4.5, I think it is bad to hardcode knowledge about ULAs 
in detecting stale prefixes. In my opinion that shows that the
algorithm is fragile. And note that this applies to all hosts.

So there might be other circumstances where some prefixes are special. A
site may have multiple ULA prefixes that have different meaning. The
same applies to regular global unicast.

So in my opinion the best way forward is to only expire prefixes quickly
if the host knows that the router sends all information in one RA.
Hosts can easily detect if a router uses one RA or multiple RAs.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 May 2020 13:06:28 -0300

> So host should keep preferred and valid lifetimes unchanged.

[This is responded below]

> algorithm is fragile. And note that this applies to all hosts.

Not sure what you mean. Could you please elaborate?
Unfolding th processing of ULA vs. non-ULA is simply 
fine-tuning/optimization: So if, say, you had a globally-reachable 
address, and now the router ceases to advertise the globally-reachable 
addresses, but starts advertising the ULA, you keep both.

One might was well not do this optimization, but it's certainly better 
this way.

WHy do you think about the algorithm being fragile?

> same applies to regular global unicast.

The logic here is:

When a prefix is missing, that's an indication that the prefix has 
become stale. Now, you might process the RAs irrelevant of ULA nad 
non-ULA, and it would also be fine.

But the logic here is that it is better to have one stale address of 
each type, than no address of that type. If you want, this is the 
algorithm being more conservative.

> Hosts can easily detect if a router uses one RA or multiple RAs.

Two things:

1) network config split into multiple RAs do not happen in practice -- 
as reported by Time Winters

2) Irrelevant from #2, from a theoretical there's no way in which a host 
can positively know whether information is split into multiple RAs or 
not. You may try to "sample" the router. But if you don't get split 
information that might simply be the result of packet loss. 
Additionally, the fact that at time T information is sent in a single 
RA, doesn't mean that that will be the case at time T+t.

The point of the algorithm is simple:
The algorithm doesn't deprecate prefixes at once. So if information is 
split into multiple RAs, then since you don't act on RAs at once, the 
algorithm will handle the split information gracefully.

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

---

From: Philip Homburg <[email-masked]>
Date: Wed, 20 May 2020 18:05:38 +0200

>WHy do you think about the algorithm being fragile?

I don't think it an optimization. Without separate processing it will fail.
That makes it fragile. 

We want something that quickly after the router reboots causes the
old prefix to be dropped. Yet, the algorithm should not drop any prefixes
due to modest packet loss. Currently, 2 out of 3 RAs can be lost without
ill effects.

Without the separately processing ULA from non-ULAs, if the router sends
ULA and non-ULAs in separate packets, and some of non-ULAs get lost, then
the host will drop the non-ULA prefixes (or the other way around).

If an organisation has a third class of address, for example if a non-ULA
prefix is used for internal addresses next to a separate prefix for
external addresses. Or two different ULA prefixes with different semantics.
Then this algorithm may drop some of the prefixes if prefixes are sent in
separate RAs, as is currently allowed.

So in my opinion, the algorithm has to work correctly without knowledge
of ULA.

>algorithm being more conservative.

Again, without special treatment of ULAs, the algorithm is dangerous. It can
take an RA with a ULA to invalid all non-ULA prefixes.

So, the ULAs need to be treated specially to make it to work at all. This
locks us into a situation where ULA, non-ULA is all that can exist.
Introducing a third type of addresses would cause this algorithm to fail.

>as reported by Time Winters

We have a mature IPv6 standard. We should not modify hosts to deal with
one corner case, and then break other things that are allowed by
the standard.

Note that even your proposed change to sending RAs still allows for the
possibility to send split RAs.

>RA, doesn't mean that that will be the case at time T+t.

If have described my algorithm before. That finds splits RAs even in the
presence of some packet loss (2 out of 3 packets getting lost).

Dealing with the case where a router suddenly switches from a single
RA to multiple RAs is tricky. My algorithm can handle that if the router
sends all RAs in a short period and there is no packet loss.

I assume that going from 1 to multiple RAs is a very rare event. If it 
isn't then my algorithm would need more work.

>algorithm will handle the split information gracefully.

Without the ULA, non-ULA split this algorithm is unsafe. Receiving a 
ULA in a single RA causes the hosts to deprecated other prefixes within
5 seconds, which causes new connections to use ULAs which fails.

It is only by recognizing ULA as special that this algorithm works.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 May 2020 08:57:55 +1200

In line...

> take an RA with a ULA to invalid all non-ULA prefixes.

I'm finding this hard to understand, since the text says:

  "o  Only RAs that advertise Global Unicast prefixes may deprecate
      Global Unicast Addresses (GUAs), while only RAs that advertise
      Unique Local prefixes may deprecate Unique Local Addresses (ULAs)."

Perhaps that should be reformulated with MUST NOT terminology to make it
clearer:

   o  RAs that advertise Global Unicast prefixes MUST NOT deprecate
      Unique Local prefixes, and RAs that advertise Unique Local
      prefixes MUST NOT deprecate Global Unicast prefixes.

> So, the ULAs need to be treated specially to make it to work at all. 

Yes, of course. They *are* special. They work even if the WAN side drops
and even if the WAN prefix changes. 

> This

Yes. If there was a 4th type of address (we already have three, counting
link-local), every router in the universe would need a fix.

Regards
    Brian
 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 May 2020 22:25:52 -0300

> I don't think it an optimization. Without separate processing it will fail.

That's a bold statement.

No, the algorithm will now fail.

If the algorithm were to not consider ULAs separately, then:
1) If the local network uses, say, ULA and non-ULA, *and*
2) The router advertises prefixes in separate packets, *and*
3) There's a lot of packet loss

Then, the algorithm would unprefer e.g. the ULA or non-ULA addresses, 
and might (depending on which values we use for the config variables) 
disable those later addresses. One can always set this second time-out 
to, say, the Router Lifetime  -- that would still clean-up stale 
addresses in reasonable time, while never removing them "erroneously".

I should point out that, from your pov, virtually every protocol you may 
engineer should be flagged as "will fail" or "fragile". SLAAC fails if 
all RAs are lost during a "Router Lifetime" period, for instance.

> due to modest packet loss. Currently, 2 out of 3 RAs can be lost without

LTA_INVALID is your friend. As noted, one might even set it to "Router 
Lifetime".

> separate RAs, as is currently allowed.

As much as you may drop a Router if RAs are lost.

[...]
> Introducing a third type of addresses would cause this algorithm to fail.

I believe this seems to me like an over statement.

As with my description above, for this to happen:
1) The same router should be advertising multiple non-ula prefixes, *and*
2) the router must be advertising different prefixes in different RAs, *and*
3) Multiple RAs need to be lost, for a considerable period of time, *and*
4) A new type of address (?) would need to be specified

Then, only then, one of such prefixes would be removed.

Me, I consider this very unlikely.

That said, I don't mind setting LTA_INVALID to the "Router Lifetime", 
and/or recommending that a host sends an unicasted RA at LTA_DEPRECATE, 
and another one at, say, time LTA_DEPRECATE + (LTA_INVALID - 
LTA_DEPRECATE) / 2.

I would expect any of these two, and particularly the setting of 
LTA_INVALID to address your concerns.

> isn't then my algorithm would need more work.

What's the basis on which the events that I deem as "unlikely" are to be 
handled because "theoretically, the std allows them", but then you 
ignore other possible scenarios by deeming them as "rare" (when they 
are, too, theoretically allowed by the spec)?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 May 2020 23:19:06 -0300

Hi, Brian,

On 20/5/20 17:57, Brian E Carpenter wrote:
[....]
> and even if the WAN prefix changes.

FWIW, this text is meant to describe what the algorithm does, as opposed 
to actually specifying anything. i.e., it's goal is to "explain" the 
algorithm. I don't mind changing the text, though.

> link-local), every router in the universe would need a fix.

In fact, if there was a 4th type of address probably all nodes would 
need a fix (including source address selection and others).

Thanks!

Cheers,

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 May 2020 17:23:14 +0200

>and even if the WAN prefix changes. 

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.

>link-local), every router in the universe would need a fix.

This is a about hosts, not routers. I think it is bad to hardcode this
kind of knowledge in all hosts. That may come back to bite us.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 May 2020 17:35:33 +0200

>3) There's a lot of packet loss

You are fixing one broken edge case with another.

Of course, we have assume packet loss. We also have to assume split-RA
because it is explictly allowed. And we can also assume there exist
many different type addresses.

>addresses in reasonable time, while never removing them "erroneously".

Unpreferring global (non-ULA) addresses breaks new connections, because
source address selection prefers ULA over non-preferred addresses.

>all RAs are lost during a "Router Lifetime" period, for instance.

RA works with a packet loss of 2 out or 3 packet. So any change to RA
processing should have to same propery otherwise the cure is worse than
the disease.

>LTA_INVALID is your friend. As noted, one might even set it to "Router 

Like I said, if an address is no longer preferred it can already break
new connections.

>4) A new type of address (?) would need to be specified

No need to specify a new type address. Today anybody can run with
2 different ULA prefixes that have different semantics. For example,
one can be used to communicate purely internally, another to communicate
with closely related organisations.

>Me, I consider this very unlikely.

I think it is very likely that people come up with complex addressing
schemes. It is also very likely there will be packet loss. Certainly on
radio link. And give the rate at which new stuff gets added to RA, it is 
very likely that RAs will be split.

>and another one at, say, time LTA_DEPRECATE + (LTA_INVALID - 

In my opinion having the host send a unicast RS (I assume that's what you
meant) and retransmitting that, just before a prefix is no longer preferred
is a lot more complex than my algorithm.

Though I have to admit, that sending a number of RS packets before 
deprecating an address would make it way more robust in many
situations.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 May 2020 15:06:48 -0300

Hello, Philip,

> You are fixing one broken edge case with another.

FWIW, one case is common, the other one isn't. But anyway... point taken 
--  That's not how the current algorithm is specified, anyway, so let's 
focus on what's actually in the I-D.

> Like I said, if an address is no longer preferred it can already break

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?

> very likely that RAs will be split.

FWIW, Section "4.4.  Conveying Information in Router Advertisement (RA) 
Messages" of the draft recommends all PIOs in the same RA.

> is a lot more complex than my algorithm.

What I was meaning was:

1) Set LTA_INVALID to "Router Lifetime", and/or,
2) Send at least one unicast message at time T= LTA_DEPRECATE + 
(LTA_INVALID - LTA_DEPRECATE) /2 . This RA, besides being an additional 
one, is sent as unicast, which tends to have a lower loss probability.

I blieve either of them should address your concern -- at the time you 
wait till "Router Lifetime", enough RAs should be getting through since 
other wise ND itself would fail (default router would be reoved, etc).

Thoughts?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 May 2020 09:32:47 +1200

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

> kind of knowledge in all hosts. That may come back to bite us.

That's true (which I think is exactly why we have the policy table
rather than fixed rules).

Regards
    Brian

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 May 2020 22:56:19 -0300

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

> kind of knowledge in all hosts. That may come back to bite us.

Please see above.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 May 2020 22:59:23 -0300

> kind of knowledge in all hosts. That may come back to bite us.

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.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 May 2020 23:01:34 -0300

> that would need to be different if there were no ULA rules in the

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.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Mon, 25 May 2020 17:16:20 +0200

[note, I'm replying to multiple messages]

>Would that address your concern?

My issue is with LTA_DEPRECATE.

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

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

>one, is sent as unicast, which tends to have a lower loss probability.

If it is after LTA_DEPRECATE then it is alread too late.

>other wise ND itself would fail (default router would be reoved, etc).

I believe that having the host send (potentially multiple) RS packets for
prefixes that are about to expire is complex. It requires having a timer
per prefix. I don't see how this complexity is warranted.

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

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.

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

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

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.

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 May 2020 13:26:59 -0300

Hello, Philip,

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

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

> 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

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.

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

> a non-ULA as part of a single DNS RR-set.

Which issue?

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

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

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

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

---

From: Philip Homburg <[email-masked]>
Date: Tue, 26 May 2020 18:13:03 +0200

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

>there were multiple-prefixes sent by multiple routers, they were 

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

>multiple non-ulas pios being sent (not the typical case, either) *and* 

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.

>same type being announced.

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

>See the rule about addresses of minumum scope. Otherwise you'd never get 

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?

>> a non-ULA as part of a single DNS RR-set.

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

>only ULA you ahve or the only non-ula you have.

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

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

>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're still playing with probabilities here.

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

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 May 2020 10:56:30 +1200

On 27-May-20 04:13, Philip Homburg wrote:
...> Upon re-reading RFC 3484 it seems that destination selection would also
> work if the host has no knowledge of ULAs.

Don't do that ;-). RFC3484 has been obsolete since 2012. As far as I know, any modern stack respects RFC6724 and its default policy table.

But yes, with no ULA prefix in the policy table, something would happen but ULA to ULA preference for local traffic is not guaranteed.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 May 2020 00:42:14 -0300

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

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).

> that has been shot down already.

No, I didn't. I think it's unnecessarily more complex than what we 
currently have in this document.

> will fail in unexpected ways if you do that. In my book that's just a bad

This document says "SHOULD NOT". That means "don't, unless you really 
know what you are doing".

> take it into account that RAs will be split.

We have kept it as "SHOULD" because it doesn't warrant a MUST. As noted: 
worst case scenario you unprefer an address.

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

It *might* fail.. who knows. As noted, the same is true for other things 
such as source address selection.

We simply can't predict the future.

> an example where a ULA doesn't get using the old table?

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.

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

As noted above, that's not true.

> Then make it a MUST. Keeping it a SHOULD is a clear indication that the

No. "SHOULD NOT" means "Don't do it, unless you really know what you are 
doing and understand the consequences". Besides, no current systems do 
this. The "SHOULD NOT" essentially reinforces current practice.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 May 2020 13:24:21 +0200

>(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.

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.

These two use cases can be analysed in the context of your proposal.

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

This is in particular bad, because aternatives do exist.

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

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 May 2020 10:55:21 -0300

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

> 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).

> to be aware of obscure corner cases of host behavior to evaluate the

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.

> type of addresses will lead to failure. So it is not a benign as you make

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.

> (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,

---

From: Philip Homburg <[email-masked]>
Date: Fri, 29 May 2020 11:17:10 +0200

>coded in the policy table.

I stop responding in this discussion. I said ULAs work fine if they are
not in the policy table. Yes, I know they are in the policy table,
that was not my point.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 May 2020 11:33:06 +1200

On 29-May-20 21:17, Philip Homburg wrote:
> not in the policy table. 

Perhaps, but then address selection works *differently*, and application layer code may be affected as a result. For that reason, they belong in this discussion as a special case.

    Brian