Subject: Possible issue with source address selection for ULAs...

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Dec 2021 14:00:00 -0500

I'm running into an interesting issue where I think the documented source
address selection algorithm produces a bad outcome.
The situation is that I have a multi-subnet home network. One subnet (A) is
connected to the main network (the one to which the CE router is connected)
using a normal IPv6 router, and has only a ULA prefix advertised for
autoconfiguration. Reachability to this prefix is advertised on the main
network using RA, but no prefix with the same global identifier is
advertised on the main network for autoconfiguration.
Separately, on the main network, there is a ULA prefix being advertised for
autoconfiguration, with a _different_ global identifier, advertised by a
stub router (which is basically an IPv6 router with some additional
behaviors specified  to allow it to self-configure).
Finally, the main network has a GUA prefix advertised by the CE router for
autoconfiguration.
In this case, a device connected to the main network will prefer the ULA
source address on the main network because it gives a longest match.
However, the CE router doesn't know how to route to this prefix, nor does
the normal IPv6 router, because they are not participating in a routing
protocol with the stub router or with each other, and because they are
supposed to ignore RAs (which I am not arguing against).
So what happens is that when a device on subnet A gets a packet from a
device on the main network, the source address will be on the ULA prefix
that's autoconfigurable on the main network, not on the GUA prefix that's
autoconfigurable on the main network. And since its only route is a default
route, it will send its reply to its default router, which will send _its_
reply to its default router (the CE router).
I bring this up because it seems to me that the assumption that a
longest-match ULA with a different global identifier is preferable to a GUA
may be wrong. I think the above configuration is largely a valid
configuration, but can't work with the current source address selection
policy. I don't expect to see this happen much in practice (e.g. the stub
router actually shouldn't be advertising an autoconfigurable prefix in this
case) but it certainly can happen if you have two RFC7084 routers connected
to the same link plus a third router that has only a self-assigned ULA on
its other link.
The way to fix this would be to add a rule before rule 8 in section 5 of
RFC 6724 that looks something like this:
Rule 7.5: prefer GUA to ULA with non-matching global identifier.If
IsULA(SA) and IsULA(D) and GlobalID(SA) != GlobalID(D) and IsULA(SB) and
GlobalID(SB) == GlobalID(D) then prefer SB.If IsULA(SA) and IsULA(D) and
GlobalID(SA) != GlobalID(D) and IsGUA(SB) then prefer SB.
Obviously this isn't quite right, but hopefully paints a clear enough
picture to get the point across.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Dec 2021 10:21:58 +1300

Ted,

A diagram would *really* help, but:

> because they are not participating in a routing protocol with the stub router or with each other

Isn't that the whole problem?

Regards
    Brian

On 07-Dec-21 08:00, Ted Lemon wrote:
> 
> I'm running into an interesting issue where I think the documented source address selection algorithm produces a bad outcome.
> The situation is that I have a multi-subnet home network. One subnet (A) is connected to the main network (the one to which the CE router is connected) using a normal IPv6 router, and has only a ULA prefix advertised for autoconfiguration. Reachability to this prefix is advertised on the main network using RA, but no prefix with the same global identifier is advertised on the main network for autoconfiguration.
> Separately, on the main network, there is a ULA prefix being advertised 
for autoconfiguration, with a _different_ global identifier, advertised by a stub router (which is basically an IPv6 router with some additional behaviors specified  to allow it to self-configure).
> Finally, the main network has a GUA prefix advertised by the CE router for autoconfiguration.
> In this case, a device connected to the main network will prefer the ULA source address on the main network because it gives a longest match. However, the CE router doesn't know how to route to this prefix, nor does the normal IPv6 router, because they are not participating in a routing protocol with the stub router or with each other, and because they are supposed to ignore RAs (which I am not arguing against).
> So what happens is that when a device on subnet A gets a packet from a device on the main network, the source address will be on the ULA prefix that's autoconfigurable on the main network, not on the GUA prefix that's 
autoconfigurable on the main network. And since its only route is a default route, it will send its reply to its default router, which will send _its_ reply to its default router (the CE router).
> I bring this up because it seems to me that the assumption that a longest-match ULA with a different global identifier is preferable to a GUA may be wrong. I think the above configuration is largely a valid configuration, but can't work with the current source address selection policy. I don't expect to see this happen much in practice (e.g. the stub router actually shouldn't be advertising an autoconfigurable prefix in this case) but it certainly can happen if you have two RFC7084 routers connected to the same link plus a third router that has only a self-assigned ULA on its 
other link.
> The way to fix this would be to add a rule before rule 8 in section 5 of RFC 6724 that looks something like this:
> Rule 7.5: prefer GUA to ULA with non-matching global identifier.If IsULA(SA) and IsULA(D) and GlobalID(SA) != GlobalID(D) and IsULA(SB) and GlobalID(SB) == GlobalID(D) then prefer SB.If IsULA(SA) and IsULA(D) and GlobalID(SA) != GlobalID(D) and IsGUA(SB) then prefer SB.
> Obviously this isn't quite right, but hopefully paints a clear enough picture to get the point across.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Dec 2021 16:26:26 -0500

> Isn't that the whole problem?

In a theoretical sense, yes, but practically speaking I don’t see how that
insight helps to solve the problem. We can’t force the market to support
routing protocols in consumer routers.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Dec 2021 13:31:24 +1300

On 07-Dec-21 10:26, Ted Lemon wrote:
> On Mon, Dec 6, 2021 at 16:22 Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> In a theoretical sense, yes, but practically speaking I don’t see how that insight helps to solve the problem. We can’t force the market to support routing protocols in consumer routers.

So homenet was a complete waste of everybody's time?

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Dec 2021 19:33:43 -0500

I didn’t say that. I said we can’t force the market to do something it
isn’t ready to do. Obviously this would be a perfect use case for homenet.
Babel would work as a routing protocol. The problem is that is not
supported by the hardware most people can buy.

On Mon, Dec 6, 2021 at 19:31 Brian E Carpenter <[email-masked]>
wrote:

> > On Mon, Dec 6, 2021 at 16:22 Brian E Carpenter <
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> > In a theoretical sense, yes, but practically speaking I don’t see how
> that insight helps to solve the problem. We can’t force the market to
> support routing protocols in consumer routers.
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 7 Dec 2021 01:54:23 +0100

Is this about a correct visual rendering of your poetry ?

                             CE   SR (Stub Router)
GUA advertised for autoconfig |   |  ULA2 advertised for autoconfig
                              |   |
        ------+-----+---------+---+----------- Main network
              |     |
              H     | ULA1 prefix advertised via RA but not for autoconfig
                    R1 ("normal IPv6 router")
                    | ULA1 prefix advertised for autoconfig
                    |
                ----+------------------------- Subnet (A)

Inline...

On Mon, Dec 06, 2021 at 02:00:00PM -0500, Ted Lemon wrote:
> using a normal IPv6 router (*R1), and has only a ULA prefix (*ULA1) advertised for
> autoconfiguration, with a _different_ global identifier (*ULA2), advertised by a

|> In this case, a device (*H) connected to the main network will prefer the ULA
|> source address (*ULA2) on the main network ??Over the GUA? because it gives a longest match.
|> For connections to where ?

I guess H will autoconfig both a GUA and ULA2 prefix and prefer ULA2
as source address for connections to a ULA1 destination ? If not, pls.
fill out the missing pieces.

> the normal IPv6 router (*R1), because they are not participating in a routing
> protocol with the stub router or with each other,

Which kinda makes me think "normal" isn't really how we should call
"routers" that don't partake in "normal" routing protocols. To me
those are all some form of "limited"-router (stub, home,...).

AFAIK, there is nothing prohibiting R1 to recognize that ULA2 is a valid
prefix on the main network and accordingly establish routing for it between
the main network and subnet A. There is probably also no explicit RFC
text saying that some form of home-router MAY/SHOULD/MUST do this though.
After all, all of this home routing is kinda hacked together, and
homenet WG proper DOES prescribe use of better routing for some form
of homenet R1 (if i am not mistaken).

> and because they are

Ah, ok. So which RFC/section says so ?

If thats a rule, it just means that one simply must not / can not
build setups like you say here.

> picture to get the point across.

What happens when you have two CE's, CE1 and CE2 on the main network
one with GUA1 the other GUA2 ? I would hope that R1 will recognize
both GUA1/GUA2 to be directly connected subnets on the uplink and forward
to H having either a GUA1 or GUA2 prefix. But if thats permitted, then
its illogical why R1 shouldn't be permitted to do the same for ULA2

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Tue, 07 Dec 2021 10:40:36 +0100

>reply to its default router (the CE router).

The question is how the host on the main network learned the address of a
host on subnet A.

It seems to me that to avoid surprises, the default for any naming system 
should be to propagate ULA addresses only to subnets where the same ULA
prefix (/48) is used.

In retrospec, it may have been a fatal mistake that we defined CPEs to be a
host on the ISP's network. If we had the CPE run a routing protocol, even
as basic a RIPng. we would have avoided issues with DHCPv6 PD. But also within
a home network where routing information does not propagate because by
default there is no routing protocol.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Dec 2021 11:24:50 -0500

> The question is how the host on the main network learned the address of a

As I said in my original email, the host on subnet A sent a message to a
host on the main network, and the host on the main network made a bad (but
correct) source address selection when responding. :)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Dec 2021 16:00:47 +1300

Thanks for that. Attached is my own desktop setup (used for testing some ANIMA stuff). Note two different ULA /64s. Works fine - but only because I set up manual routes on the Pi and the Linux laptop (mainly because I was too lazy to install RPL or something).

Without routing, of course it doesn't work.

Regards
    Brian

On 08-Dec-21 05:27, Ted Lemon wrote:
> Here's a diagram that my colleague who reported the bug has drawn of his home network (the things arrows point to are networks):
> 
> image.png
> 
> On Mon, Dec 6, 2021 at 4:22 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Ted,
> 
>      > The situation is that I have a multi-subnet home network. One subnet (A) is connected to the main network (the one to which the CE router 
is connected) using a normal IPv6 router, and has only a ULA prefix advertised for autoconfiguration. Reachability to this prefix is advertised on 
the main network using RA, but no prefix with the same global identifier is advertised on the main network for autoconfiguration.
>      > In this case, a device connected to the main network will prefer 
the ULA source address on the main network because it gives a longest match. However, the CE router doesn't know how to route to this prefix, nor does the normal IPv6 router, because they are not participating in a routing protocol with the stub router or with each other, and because they are supposed to ignore RAs (which I am not arguing against).
>     autoconfigurable on the main network. And since its only route is a 
default route, it will send its reply to its default router, which will send _its_ reply to its default router (the CE router).
>      > I bring this up because it seems to me that the assumption that a longest-match ULA with a different global identifier is preferable to a 
GUA may be wrong. I think the above configuration is largely a valid configuration, but can't work with the current source address selection policy. I don't expect to see this happen much in practice (e.g. the stub router actually shouldn't be advertising an autoconfigurable prefix in this case) but it certainly can happen if you have two RFC7084 routers connected to the same link plus a third router that has only a self-assigned ULA on its
>      > Rule 7.5: prefer GUA to ULA with non-matching global identifier.If IsULA(SA) and IsULA(D) and GlobalID(SA) != GlobalID(D) and IsULA(SB) 
and GlobalID(SB) == GlobalID(D) then prefer SB.If IsULA(SA) and IsULA(D) and GlobalID(SA) != GlobalID(D) and IsGUA(SB) then prefer SB.
>      > [email-masked] <mailto:[email-masked]>
>      > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 08 Dec 2021 15:29:20 +0100

>    As I said in my original email, the host on subnet A sent a
>    message to a host on the main network, and the host on the main
>    network made a bad (but correct) source address selection when
>    responding. :)

I don't know what application does that, but in general it is not smart
to send a reply with a different source address.

The original host, but also firewalls may drop the reply packet.

---

From: [email-masked]
Date: Wed, 8 Dec 2021 15:57:06 +0100

> As I said in my original email, the host on subnet A sent a message to a host on the main network, and the host on the main network made a bad (but correct) source address selection when responding. :)

I think the jury is still out regarding the wisdom of multi-addressing in IPv6.

I don't think you will find a fixed SAS policy that will be functional in every use case.
That's why there are options to configure the SAS table in DHCP for example.

There are a few more general solutions one could consider, like a
SADR routing on the hosts (with a SADR routing protocol).

The complexity and requirements that SAS puts on applications and host stack over just a single address host might not be worth it. 25 years in, it's not obvious at least.

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Dec 2021 03:21:26 +1100

On Thu, 9 Dec 2021, 01:57 , <[email-masked]> wrote:

> The complexity and requirements that SAS puts on applications and host
> stack over just a single address host might not be worth it. 25 years in,
> it's not obvious at least.
>

I have some experience with the usefulness of device multiaddressing from
IPv4.

As an example, I've used different IPv4 addresses on routers (on different
loopback interfaces) to represent different functions.

There was an "OAM" loopback IPv4 address used for ssh, SNMP, BGP etc.

There were other loopbacks/IPv4 addresses used for L2TP and other function
endpoints.

The advantage was I could move the tunnel endpoints to different routers
just by moving that special use IPv4 address, with the routing protocols
taking care of sending traffic to the new location rather than having to
reconfigure remote tunnel endpoints.

RFC1681 by Steve Bellovin looks to be the origin of IPv6 multi addressing,
describing use cases.

Having introduced IPv6 multiaddressing recently to ISP Helpdesk people, an
analogy I've used is to imagine having multiple phone numbers for your
mobile phone so you can do things like having a number for family and
friends, a number for when you're on call, and other numbers you give out
to different businesses you deal with. You could abandon a phone number to
stop receiving calls from that party.

We can do similar sorts of things with IPv6 multiaddressing, I think it is
mainly that people haven't really thought about how to leverage it because
of familiarity of a single IPv4 address per host.

Regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Dec 2021 11:33:42 -0500

One obvious benefit of multiple addresses is that it enables link-local
addressing, which allows us to get functionality out of the network even
when there is no infrastructure other than the link itself.

Another benefit to multiple addresses is that it lets us survive
renumbering events without unnecessary service interruptions: using a ULA
on the local network means that if my ISP goes away or does a flash
renumber, it only breaks my connections through the ISP, and not my home
network connections.

Another benefit of multiple addresses is that it allows us to do graceful
renumbering.

I don't think there's any question that multiple addresses are useful. And
source address/destination address selection is really good. I was
skeptical at first, but I've got enough experience with it at this point to
feel really impressed with the thorough treatment that the RFC gives to the
problem, and I've seen it do the right thing in action _a lot_.

So my point in raising this issue is not to say "source/destination address
selection is hard, let's do something easier." It's to investigate whether
my intuition about this particular edge case is right or not.

So maybe a better way to approach this is to ask the question: does anybody
think that the change I proposed is a _bad idea_ for any reason other than
that it adds a bit of complexity? Do you know of a situation where things
would break if some IP stack started exhibiting this behavior, whether it
gets standardized or not?

On Wed, Dec 8, 2021 at 11:21 AM Mark Smith <[email-masked]> wrote:

>> > As I said in my original email, the host on subnet A sent a message to
>> a host on the main network, and the host on the main network made a bad
>> (but correct) source address selection when responding. :)
>>

---

From: Markku Savela <[email-masked]>
Date: Wed, 8 Dec 2021 19:03:36 +0200

I'm just jumping in middle of discussion, so the following may already 
be addressed or not relevant to thread, but...

I thought it was long ago discussed that hosts should remember from each 
advertised prefix the advertising router. Once next hop router is known, 
the source address should belong to one of the prefixes advertised by 
that router.

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 8 Dec 2021 17:07:19 +0000

Then we are reinventing the wheel here: https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-01 (beginning of section 6)
It is a part of the proposition.

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Markku Savela
Sent: Wednesday, December 8, 2021 8:04 PM
To: [email-masked]
Subject: Re: Possible issue with source address selection for ULAs...

I'm just jumping in middle of discussion, so the following may already be addressed or not relevant to thread, but...

I thought it was long ago discussed that hosts should remember from each advertised prefix the advertising router. Once next hop router is known, the source address should belong to one of the prefixes advertised by that router.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 08 Dec 2021 18:08:18 +0100

> I don't think you will find a fixed SAS policy that will be functional
> in every use case.  That's why there are options to configure the
> SAS table in DHCP for example.

I can see such a SAS policy in an enterprice context. Could be delivered
using DHCP, could be something else.

However, the current problem is a home network with some random elements
in it. Who is going to write and publish the SAS policy?

> SADR routing on the hosts (with a SADR routing protocol).

The first step should be to have SADR routing on routers. 

There is one thing we don't have in hosts at the moment, and that is to 
tag a destination unreachable with the source address.

If we had that, we could have new rule in SAS, avoid source addresses for
which the destination is unreachable.

That would solve the original problem if the host retries, i.e., using
the ULA would result in a destination unreachable. Then the next round,
the GUA would be selected.

> The complexity and requirements that SAS puts on applications and
> host stack over just a single address host might not be worth it.
> 25 years in, it's not obvious at least.

Many devices have more than one interface. So a large part of the 
complicity will be there anyhow.

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 8 Dec 2021 17:09:31 +0000

I would agree too
that a few addresses for 1 interface have use cases.
It is just a problem how these addresses are appointed.
Ed/
From: ipv6 [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, December 8, 2021 7:34 PM
To: Mark Smith <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: Possible issue with source address selection for ULAs...

One obvious benefit of multiple addresses is that it enables link-local addressing, which allows us to get functionality out of the network even when there is no infrastructure other than the link itself.

Another benefit to multiple addresses is that it lets us survive renumbering events without unnecessary service interruptions: using a ULA on the local network means that if my ISP goes away or does a flash renumber, it only breaks my connections through the ISP, and not my home network connections.

Another benefit of multiple addresses is that it allows us to do graceful renumbering.

I don't think there's any question that multiple addresses are useful. And source address/destination address selection is really good. I was skeptical at first, but I've got enough experience with it at this point to feel really impressed with the thorough treatment that the RFC gives to the problem, and I've seen it do the right thing in action _a lot_.

So my point in raising this issue is not to say "source/destination address selection is hard, let's do something easier." It's to investigate whether my intuition about this particular edge case is right or not.

So maybe a better way to approach this is to ask the question: does anybody think that the change I proposed is a _bad idea_ for any reason other than that it adds a bit of complexity? Do you know of a situation where things would break if some IP stack started exhibiting this behavior, whether it gets standardized or not?

On Wed, Dec 8, 2021 at 11:21 AM Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

I have some experience with the usefulness of device multiaddressing from IPv4.

As an example, I've used different IPv4 addresses on routers (on different loopback interfaces) to represent different functions.

There were other loopbacks/IPv4 addresses used for L2TP and other function endpoints.

The advantage was I could move the tunnel endpoints to different routers just by moving that special use IPv4 address, with the routing protocols taking care of sending traffic to the new location rather than having to reconfigure remote tunnel endpoints.

RFC1681 by Steve Bellovin looks to be the origin of IPv6 multi addressing, describing use cases.

Having introduced IPv6 multiaddressing recently to ISP Helpdesk people, an analogy I've used is to imagine having multiple phone numbers for your mobile phone so you can do things like having a number for family and friends, a number for when you're on call, and other numbers you give out to different businesses you deal with. You could abandon a phone number to stop receiving calls from that party.

We can do similar sorts of things with IPv6 multiaddressing, I think it is mainly that people haven't really thought about how to leverage it because of familiarity of a single IPv4 address per host.

Regards,
Mark.

Best regards,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Dec 2021 12:09:33 -0500

I'm not seeing it. Can you point at the text that you think addresses this
problem?

On Wed, Dec 8, 2021 at 12:07 PM Vasilenko Eduard <vasilenko.eduard=
[email-masked]> wrote:

> Then we are reinventing the wheel here:
> https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-01
> (beginning of section 6)
> I'm just jumping in middle of discussion, so the following may already be
> addressed or not relevant to thread, but...
>
> the source address should belong to one of the prefixes advertised by that
> router.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Dec 2021 12:11:53 -0500

I think we can take it as read that the right solution to this problem is a
full routing protocol on the home network. However, my question is about
what a host can do to avoid this problem, given that there is no full
routing protocol running on the home network, which is a problem we can't
immediately solve.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Dec 2021 12:07:54 -0500

That doesn't help, unfortunately. The router that advertised the ULA on the
main network is still reachable; the problem is that the /different/ ULA on
the test network gets a longest-match, but there's no route on the test
network for that prefix, and the test network router doesn't have a route
for the prefix because it's a router and doesn't listen to RAs.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 08 Dec 2021 18:15:05 +0100

>    So maybe a better way to approach this is to
>    ask the question: does anybody think that the change I proposed
>    is a _bad idea_ for any reason other than that it adds a bit of
>    complexity? Do you know of a situation where things would break
>    if some IP stack started exhibiting this behavior, whether it

Suppose that two organisations that each have their own ULA, create a
joined network. Then it seems to me that with your change, SAS would
actively avoid using ULA if a host in one organistion would communicate
with a host in the other.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 08 Dec 2021 18:24:28 +0100

>    I think we can take it as read that the right solution to this
>    problem is a full routing protocol on the home network. However,
>    my question is about what a host can do to avoid this problem,
>    given that there is no full routing protocol running on the home
>    network, which is a problem we can't immediately solve.

I have to admit, in this context, Eduard's suggestion seems the most
general.

Basically, a host can make a list of routers that can be used to forward
traffic to the destination. Then limit the SAS to source addresses announced
by those routers and at the end use the router that matches the source 
addresses.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 8 Dec 2021 17:38:30 +0000

Ted Lemon wrote on 08/12/2021 17:11:
> I think we can take it as read that the right solution to this problem 
> is a full routing protocol on the home network.

I was mid-reply on an email which pointed this out, and was stuck on how 
to suggest this without causing too much offence, so thank you for 
pre-empting  :)

> However, my question is 
> about what a host can do to avoid this problem, given that there is no 
> full routing protocol running on the home network, which is a problem we 
> can't immediately solve.

Couple of stream-of-consciousness thoughts:

1. your network is broken and you want to implement a protocol change in 
ipv6 as a workaround.  Well, ok.  Ultimately there's some complexity on 
your network, and this complexity has consequences.  The question is how 
to address the consequences: reconfig of the network to remove the 
multiple networks, ensuring that all networks have reachability to all 
others as appropriate, or change the underlying protocol to change how 
SAS works..

Moving the mountain is rarely the best approach.

2. your proposed fix may not be a bad idea in its own right, but not 
because of the reasons that you want it.

Nick

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 8 Dec 2021 18:15:49 +0000

It is one of 9 proposed modifications in the draft.
This one has been just touched by Markku – see below.
The draft claims that it is mandatory to fix the MHMP environment. Unfortunately, it is not enough, additional things are needed when MHMP is “under the change” (some links are broken).
It is exactly what I mean when told a few times here that RFC 8028 is just “the right concept without details”.
These are “details”.

   * Section 6.3.6<https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-01#section-6.3.6> (Default Router Selection) of [ND<https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-01#ref-ND>], add an initial
   policy to default router selection:

  0) For the cases when a particular implementation of ND does know
     the source address at the time of default router selection
     (it means that source address was chosen first),
     then default routers that advertise the prefix for respective
     source address SHOULD be preferred over routers that do not
     advertise respective prefix.
Ed/
From: ipv6 [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, December 8, 2021 8:10 PM
To: Vasilenko Eduard <vasilenko.eduard=[email-masked]>
Cc: [email-masked]
Subject: Re: Possible issue with source address selection for ULAs...

I'm not seeing it. Can you point at the text that you think addresses this problem?

On Wed, Dec 8, 2021 at 12:07 PM Vasilenko Eduard <vasilenko.eduard=[email-masked]<mailto:[email-masked]>> wrote:
Then we are reinventing the wheel here: https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-01 (beginning of section 6)
It is a part of the proposition.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Dec 2021 13:36:10 -0500

> with a host in the other.

I don't think the change I proposed has this effect. It doesn't exclude the
foreign ULA—it just doesn't prefer it. If it is the only alternative, it is
still a valid address to select, but if there's a GUA we'd prefer that.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 08 Dec 2021 20:01:29 +0100

>    I don't think the change I proposed has this effect. It doesn't
>    exclude the foreign ULAit just doesn't prefer it. If it is the
>    only alternative, it is still a valid address to select, but if
>    there's a GUA we'd prefer that.

How is that better? Preferring a GUA to talk to a ULA is likely to lead
to surprises. It makes firewalls harder. Instead allowing the relatively
stable ULAs, you would have to allow GUAs that might change.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Dec 2021 14:16:33 -0500

I think it's not completely inaccurate to say that the network setup I
described is broken, but it's not completely accurate either. What I'm
describing is a situation where a perfectly valid network configuration
stopped working because of an automatic behavior that I think is also
perfectly valid. Certainly we can cure this problem by adding routing, but
that's not practicable at the moment, and I don't actually know what it
will take to get to where it is.

So given that assumption, what we are seeing here is something that
certainly could happen, and that the owner of the network might not know
how to fix. So the question I'm trying to get to is whether (a) it's worth
addressing this issue, and (b) what harm addressing it in the way I'm
suggesting might cause.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Dec 2021 14:20:25 -0500

In the environment you're describing (a large enterprise setting), it seems
unlikely that this is a real concern. In point of fact, using ULAs the way
you've described in an enterprise setting is probably more trouble than
it's worth—the reason we even talk about it is because we're used to
enterprises using net 10 for numbering IPv4 networks, but they do that
because GUAs are scarce, not because it's a particularly good idea. In a
large enterprise setting, the enterprise is probably an AS and can get its
own GUA allocation; when two enterprises of this size merge, they will both
be ASes and will both have GUA allocations.

I do appreciate you answering my question by coming up with a potential
issue that my proposed solution might cause, but I don't think it's a very
compelling issue—it's hard for me to imagine a situation where it would
actually produce a significant failure. Granted, the network configuration
that we're talking about here is also a bit of an edge case.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Dec 2021 14:21:55 -0500

On Wed, Dec 8, 2021 at 2:20 PM Ted Lemon <[email-masked]> wrote:

> In the environment you're describing (a large enterprise setting), it
> seems unlikely that this is a real concern. In point of fact, using ULAs
> the way you've described in an enterprise setting is probably more trouble
> than it's worth—the reason we even talk about it is because we're used to

To be clear, IPv4 GUAs are scarce. IPv6 GUAs are not. So the motivation for
using a ULA in this case can't be that GUAs are scarce, and that's the
motivation for using net 10.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Dec 2021 09:05:37 +1300

On 09-Dec-21 08:21, Ted Lemon wrote:
> On Wed, Dec 8, 2021 at 2:20 PM Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     In the environment you're describing (a large enterprise setting), it seems unlikely that this is a real concern. In point of fact, using ULAs the way you've described in an enterprise setting is probably more trouble than it's worth—the reason we even talk about it is because we're used to enterprises using net 10 for numbering IPv4 networks, but they do that because GUAs are scarce, not because it's a particularly good 
idea. In a large enterprise setting, the enterprise is probably an AS and 
can get its own GUA allocation; when two enterprises of this size merge, they will both be ASes and will both have GUA allocations.
> 
> 
> To be clear, IPv4 GUAs are scarce. IPv6 GUAs are not. So the motivation 
for using a ULA in this case can't be that GUAs are scarce, and that's the motivation for using net 10.

Indeed. There are really two possible motivations for using a ULA prefix:

1) Keep local traffic local by construction [RFC4864].

2) Generate addresses without dependency on the outside world in any way. 
That is the reason ULAs are a perfect solution for the ANIMA autonomic control plane [RFC8994].

There might be a third motivation: your ISP doesn't give you a short enough GUA prefix to do enough subnetting. That would be sad.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Dec 2021 15:12:20 -0500

> That is the reason ULAs are a perfect solution for the ANIMA autonomic

This is why we do the same thing for stub routers in the absence of DHCPv6
PD support.

There might be a third motivation: your ISP doesn't give you a short enough
> GUA prefix to do enough subnetting. That would be sad.
>

That would be sad indeed.

BTW, another reason why Philip's example failure mode doesn't really work
is that in the case that you actually for some reason have an enterprise
network where there are two ULA prefixes, in order for this to work, you've
got to have routing working, and you have a network operator, who
presumably can publish a policy table.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 08 Dec 2021 22:13:09 +0100

>    BTW, another reason why Philip's
>    example failure mode doesn't really work is that in the case
>    that you actually for some reason have an enterprise network
>    where there are two ULA prefixes, in order for this to work,
>    you've got to have routing working, and you have a network
>    operator, who presumably can publish a policy table.

If connecting two organisations with separate ULA prefixes requires that a 
policy table reaches every host and every application then that is almost
certain going to fail.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Dec 2021 16:26:55 -0500

That's true, but the policy table is only needed in the case that there is
a renumbering event, so it's an optimization, not an operational
requirement. Best effort should be fine.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Dec 2021 11:28:31 +1300

> policy table reaches every host and every application then that is almost

This does remind me somewhat of the de facto routing table distributed as
part of many corporate VPN solutions, so that a remotely-connected employee
routes over the VPN for all company internal prefixes.

Maybe the IETF owes the world a protocol mechanism for distributing the
policy table. Oh look, we have one [RFC7078].

     Brian

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 8 Dec 2021 23:17:28 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Philip Homburg

> If connecting two organisations with separate ULA prefixes requires
> that a policy table reaches every host and every application then that
> is almost certain going to fail.

Or, use NPTv6!!

Bert

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Dec 2021 17:43:25 -0500

> be ASes and will both have GUA allocations.

s/large enterprise/a large *network focused IT* enterprise setting/

most enterprises are just not that clueful, and frankly, will wind up with ULAs.
Many large software enterprises don't have enough network clue.

It's really worth solving this; if only to reduce the number of brain cells
the clueful people have to spend on this.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Dec 2021 19:29:58 -0500

> Many large software enterprises don't have enough network clue.

I don't buy this. ULAs are extra work, and require clue to get right.
Particularly during a network merge between two networks having two ULA
global IDs. It's much easier to just get a GUA prefix from your ISP. There
are network service companies that do this kind of thing as a business so
that every enterprise in the world doesn't have to have a clue about this.
Of course, such companies may well use ULAs, but there will still be clue
available when it's needed.

> the clueful people have to spend on this

Which "this?"

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 10 Dec 2021 08:26:25 +0000

Hi Ted,
I do not understand what is the problem to have many ULAs in one domain?
Of course, it is more convenient to have 1, many would need a little more routing.
But we have plenty of IPv4 networks where many-many unaggregated prefixes are used.
It is not about routing to the host, Just the default routers should know paths to all subnets.
It is a very normal/typical situation for any Enterprise.
From that respect, no difference between GUA, ULA, RFC 1918, public IPv4.

Of course, I assume no collision between ULAs or RFC 1918.
Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Friday, December 10, 2021 3:30 AM
To: Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: Possible issue with source address selection for ULAs...

On Thu, Dec 9, 2021 at 5:44 PM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:
s/large enterprise/a large *network focused IT* enterprise setting/

I don't buy this. ULAs are extra work, and require clue to get right. Particularly during a network merge between two networks having two ULA global IDs. It's much easier to just get a GUA prefix from your ISP. There are network service companies that do this kind of thing as a business so that every enterprise in the world doesn't have to have a clue about this. Of course, such companies may well use ULAs, but there will still be clue available when it's needed.

Which "this?"

---

From: Philip Homburg <[email-masked]>
Date: Sat, 11 Dec 2021 11:43:10 +0100

>    I'm running into an interesting issue where I think the documented
>    source address selection algorithm produces a bad outcome.  The
>    situation is that I have a multi-subnet home network. One subnet
>    (A) is connected to the main network (the one to which the CE
>    router is connected) using a normal IPv6 router, and has only
>    a ULA prefix advertised for autoconfiguration. Reachability to
>    this prefix is advertised on the main network using RA, but no
>    prefix with the same global identifier is advertised on the main
>    network for autoconfiguration.  Separately, on the main network,
>    there is a ULA prefix being advertised for autoconfiguration,
>    with a _different_ global identifier, advertised by a stub router
>    (which is basically an IPv6 router with some additional behaviors
>    specified  to allow it to self-configure).  Finally, the main
>    network has a GUA prefix advertised by the CE router for
>    autoconfiguration.  

There are some things I don't understand about this setup. I assume that 
the 3 routers involved are in the default configuration. Obviously if there
is some manual configuration going on an it fails then, don't do that then.

The part that strikes me as weird (for a default configuration) is the main
router. The main has generated a ULA prefix, delegated that to the router 
that connects subnet A. 

However, subnet A does not receive the global prefix. Why is that? Second
the main router does not advertise a ULA prefix for autoconfiguration.
Why is that?

I don't see why that would be the default configuration of any CPE. If it is
the result of manual configuration, then don't do that then.

The second weird thing is the 'stub router'. Connecting multiple routers
to a subnet without a routing protocol is a receipe for disaster. It can work
if all hosts select source addresses based on outgoing router, but that
is not the case the moment. Also in this description, the stub router serves
no purpose other then to cause problems. It would be different if the
stub router was a redundant uplink. But in that case, without a routing
protocol, things are likely to fail.

So in my opinion, this is a misconfigured network.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Dec 2021 11:45:27 -0500

> Finally, the main network has a GUA prefix advertised by the CE router for

I made a diagram. I think that it's the same as Toerless' diagram.
it is here: https://www.sandelman.ca/tmp/stub-network.svg
and attached.

Some questions before I go into the problem to make sure that I understand
correctly.  You say that R1 is a "normal" router, but in what way is it not a
stub router?

In my diagram, I've shown the RAs from R1 (and router B) as being offlink,
which is what I thought the stub-networks-02, section 3.1 said, but
re-reading it, I see it saying they would be onlink RAs.
Reading stub-network-ps, section 2.2, _Stub reachability using RA_
the reachability is provided by RIOs, not by PIOs with offlink.
I should update my diagram?

{That tells me that we need more text before section 3 of stub-networks to
explain the situation better, before going into a solution.}

At this point, I just want to confirm the problem statement.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Dec 2021 11:49:11 -0500

> available when it's needed.

ULAs are things that junior network engineers can configure.

Getting a GUAs from your ISP may involve managers, accounting, ISP billing, and
possibly many other IPv6 hostile people interactions.
I wish it wasn't like this.

If IPv6 GUA allocations were really free, then these other entities might not be
involved, but this is not the case in my experience.

    > Which "this?"

this = Connecting two stub routers.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Dec 2021 11:52:17 -0500

> router. The main has generated a ULA prefix, delegated that to the router

Has it?  I didn't get that from Ted's original description.
If so my diagram is wrong.

    > the main router does not advertise a ULA prefix for autoconfiguration.

I'm not convinced it doesn't advertise the ULA.
a) It could be that the Main Router (H) only got one /64.
b) It could be that the Main Router if flapping, and R1 hasn't gotten around
   to asking for a GUA, and last time, there was no connectivity.

    > So in my opinion, this is a misconfigured network.

There are many misconfigured networks.
The question is how do we get the right signaling so that the parts of the
network that can function, do function, so that someone or something can fix
it.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Dec 2021 15:36:03 -0500

Your diagram shows the home router advertising a ULA prefix, but that is in
fact wrong—the home router is not advertising a ULA prefix on network M in
your diagram. The only ULA prefix being advertised on network M is being
advertised by the stub router. There is no prefix delegation in this
network.

I don't think Philip's characterization of this network as "broken" is
entirely wrong, but it's not entirely right, either. It's broken in the
sense that it's not working, but it's not broken in the sense that the
operator made a mistake.

Michael, the difference between a "stub router" and a "normal router" is
that the stub router connects to the network and establishes an on-link
prefix automatically when no usable on-link prefix is present. A "normal
router" does not. The situation here is happening because the stub router
(B) incorrectly determines that there is no usable on-link prefix on the
link and starts advertising one; while this is going on, source address
selection chooses the mistakenly-advertised ULA rather than the GUA because
of longest-match when communicating to a host on network A.

The thing is, the stub router's behavior is the wrong behavior for a stub
router, but it's not wrong behavior for a router. It's perfectly valid for
a router to advertise an on-link ULA prefix, and indeed many IPv6-capable
home routers do, because the CE router requirements document says to. So
from the network operator's perspective, they configured a router in a way
that worked and was valid, and then they added another router and suddenly
hosts on network A became unreachable. This seems broken to me. My point in
bringing this up is not that the stub router's behavior is correct, but
rather that the situation that we found ourselves in as a result of the
stub router's behavior could occur in a situation where "router B" is in
fact behaving correctly, and that this would still break reachability to
network A.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Dec 2021 16:06:12 -0500

Diagram updated and move to:
   https://www.sandelman.ca/SSW/ietf/homenet/diagrams/

    > advertised by the stub router. There is no prefix delegation in this

okay.  I will fix that.  But, the Home Router (W) *is* advertising a GUA?
That it isn't to RFC7084-spec, but I'll take that tweak.
The Home Router could have that part turned off, or not be RFC7084 compliant, right?

    > router" does not.

Does the R1 router for A have a ULA prefix? Or a GUA prefix that it got from W?
How?  HNCP? (I assume not...) DHCPv6-PD?  Does W know about R1's A-network prefix?

    > The situation here is happening because the stub router

This does seems reasonable given race conditions, hidden node issues with wifi,
flaky wiring, flaky power, ...

    > home routers do, because the CE router requirements document says to.

Is R1 an RFC7084 router, but W is not?

    > So

I'm gonna try to get the assumption right before I try to understand the
situation in which things fail. :-)

I'm sorry to be a pain here, but I think that it's best that we all
understand how things got this way.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Dec 2021 07:21:47 -0500

> The Home Router could have that part turned off, or not be RFC7084

Yes. It's possible that the operator disabled the ULA because it was
breaking connectivity to network A. :)

> How?  HNCP? (I assume not...) DHCPv6-PD?  Does W know about R1's A-network

The router interfaces of the non-stub routers on network M do not have ULA
prefixes from the prefix advertised by the stub router on network M because
they are normal routers and do not listen to RAs.

> flaky wiring, flaky power, ...

Exactly.

> Is R1 an RFC7084 router, but W is not?

Maybe. Or maybe the operator configured it to provide a ULA. I don't think
it matters for digging into this question. I think it's valid for the
operator to have configured it the way it's configured.

> understand how things got this way.

No worries. I don't entirely agree, but I do agree that it's important to
evaluate whether this is a plausible scenario. The question I'm asking
arose as a result of something that I think was a bug, so I am not
convinced that examining the /exact/ scenario closely adds a lot of value.
The question is whether we believe this could happen IRL with things that
aren't buggy (I have an example of how it could happen), whether we want to
mitigate this problem, and whether my proposed mitigation is the right one.

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 21 Dec 2021 08:57:42 +0000

Hi Ted,

It seems like there are issues if we use ULA in carrier networks, at least it is not easy to handle as my understanding.

One more consideration regarding using ULA as the source address: When an error like PMTU exceeding or EH errors happen in a node, it needs to reply ICMP message like packet too big or other error message to the source node. If the packet come from outside the domain, the source ULA address will leak outside the domain?

If we do not allow forwarding the packet outside the domain if the source address is an ULA address, then the source node(of sending the data packet) will not know why the packet is lost at all, so problem comes? I think this is a normal operation problem which may happen in any network.

Respect,
Cheng

From: ipv6 [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Monday, December 13, 2021 8:22 PM
To: Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: Possible issue with source address selection for ULAs...

On Sun, Dec 12, 2021 at 4:06 PM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:
okay.  I will fix that.  But, the Home Router (W) *is* advertising a GUA?
That it isn't to RFC7084-spec, but I'll take that tweak.
The Home Router could have that part turned off, or not be RFC7084 compliant, right?

Yes. It's possible that the operator disabled the ULA because it was breaking connectivity to network A. :)

The router interfaces of the non-stub routers on network M do not have ULA prefixes from the prefix advertised by the stub router on network M because they are normal routers and do not listen to RAs.

Exactly.

Maybe. Or maybe the operator configured it to provide a ULA. I don't think it matters for digging into this question. I think it's valid for the operator to have configured it the way it's configured.

No worries. I don't entirely agree, but I do agree that it's important to evaluate whether this is a plausible scenario. The question I'm asking arose as a result of something that I think was a bug, so I am not convinced that examining the /exact/ scenario closely adds a lot of value. The question is whether we believe this could happen IRL with things that aren't buggy (I have an example of how it could happen), whether we want to mitigate this problem, and whether my proposed mitigation is the right one.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Dec 2021 08:18:15 -0500

Do you mean because the two routers have no knowledge of the ULA on network
A, they would send the ICMP response in the wrong direction? I think in
this case R1 would have an address on the ULA prefix on its interface on
network A, so that wouldn't be a problem. An ICMP port unreachable from H1
would not reach a host on network A, however, so you are correct about
that. But I don't think it really changes the problem.

On Tue, Dec 21, 2021 at 3:57 AM Chengli (Cheng Li) <[email-masked]> wrote:

> Hi Ted,
>
>
>
> It seems like there are issues if we use ULA in carrier networks, at least
> it is not easy to handle as my understanding.
>
>
>
> One more consideration regarding using ULA as the source address: When an
> error like PMTU exceeding or EH errors happen in a node, it needs to reply
> ICMP message like packet too big or other error message to the source node.
> If the packet come from outside the domain, the source ULA address will
> leak outside the domain?
>
>
>
> If we do not allow forwarding the packet outside the domain if the source
> address is an ULA address, then the source node(of sending the data packet)
> will not know why the packet is lost at all, so problem comes? I think this
> is a normal operation problem which may happen in any network.
>
>
>
> Respect,
>
> Cheng
>
>
>
>
>
> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *Ted Lemon
> *Sent:* Monday, December 13, 2021 8:22 PM
> *To:* Michael Richardson <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: Possible issue with source address selection for ULAs...
>
>
>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 21 Dec 2021 14:00:47 +0000

Hi Ted,

No, I may propose a new scenarios.

Think about a native IPv6 packet (A, B) is forwarding in your network. And an PMTU error or EH processing error occurs, then the node R1 should send back the ICMP message back to the source address B.

Therefore, a (ULA_SA, A) packet is sent back to the address A, in this way the source address ULA_SA is leaked.  We can avoid this by dropping  the packet (ULA_SA, A) at the edge node, then the source node will not have the idea of why my packet is lost ☹.

So I think ULA can be used ONLY in an ISOLATED network, where the ULA route/address will not be leaked outside the domain. The isolated means we will not accept any packets from outside the domain.
Otherwise, issues come: the ULA will leak anyway or the ICMP message will be dropped any way. Adding an extra GUA address may solve this problem.

Respect,
Cheng

From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, December 21, 2021 9:18 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: Possible issue with source address selection for ULAs...

Do you mean because the two routers have no knowledge of the ULA on network A, they would send the ICMP response in the wrong direction? I think in this case R1 would have an address on the ULA prefix on its interface on network A, so that wouldn't be a problem. An ICMP port unreachable from H1 would not reach a host on network A, however, so you are correct about that. But I don't think it really changes the problem.

On Tue, Dec 21, 2021 at 3:57 AM Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ted,

Respect,
Cheng

From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ted Lemon
Sent: Monday, December 13, 2021 8:22 PM
To: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Possible issue with source address selection for ULAs...

Exactly.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Dec 2021 09:16:34 -0500

In the case you describe, source address selection would not choose a ULA,
so there would be no issue.

On Tue, Dec 21, 2021 at 09:01 Chengli (Cheng Li) <[email-masked]> wrote:

> Think about a native IPv6 packet (A, B) is forwarding in your network. And
> an PMTU error or EH processing error occurs, then the node R1 should send
> back the ICMP message back to the source address B.
>
>
>
> Therefore, a (ULA_SA, A) packet is sent back to the address A, in this way
> the source address ULA_SA is leaked.  We can avoid this by dropping  the
> packet (ULA_SA, A) at the edge node, then the source node will not have the
> idea of why my packet is lost L.
>
>
>
> So I think ULA can be used ONLY in an ISOLATED network, where the ULA
> route/address will not be leaked outside the domain. The isolated means we
> will not accept any packets from outside the domain.
>
> Otherwise, issues come: the ULA will leak anyway or the ICMP message will
> be dropped any way. Adding an extra GUA address may solve this problem.
>
>
>
> Respect,
>
> Cheng
>
>
>
>
>
> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Tuesday, December 21, 2021 9:18 PM
> *To:* Chengli (Cheng Li) <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>; [email-masked]
> Do you mean because the two routers have no knowledge of the ULA on
> network A, they would send the ICMP response in the wrong direction? I
> think in this case R1 would have an address on the ULA prefix on its
> interface on network A, so that wouldn't be a problem. An ICMP port
> unreachable from H1 would not reach a host on network A, however, so you
> are correct about that. But I don't think it really changes the problem.
>
>
>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 21 Dec 2021 14:18:39 +0000

Yes, I mean if we only have ULA, then the source address selection MUST choose ULA, so issues come.  Unless we have multiple address configured.

Sent: Tuesday, December 21, 2021 10:17 PM

In the case you describe, source address selection would not choose a ULA, so there would be no issue.

On Tue, Dec 21, 2021 at 09:01 Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ted,

Respect,
Cheng

From: Ted Lemon [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 21, 2021 9:18 PM
To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Possible issue with source address selection for ULAs...

Respect,
Cheng

Exactly.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Dec 2021 13:37:42 -0500

The problem is that in your example, a packet came _from_ the internet (or
at least a GUA) _to_ your ULA. That's not possible unless routing is
working, but if it does happen, the GUA is reachable, so presumably either
the ULA sourced packet will get to the GUA, or it will be dropped somewhere
along the path. But it can't have come from a GUA unless there was a route
to the ULA. If you are thinking of configuring routers that route packets
from/to the internet with ULAs only, don't do that—it's not a valid
configuration.

The issue I'm pointing to is similar, but the problem is that both links
have a ULA, but only one link has a route to the other link's ULA, whereas
the other link has only a route to the GUA. And source address selection
winds up choosing the (non-routable) ULA as a source address because it's a
ULA, not because it matches the other ULA in any meaningful way. In this
case I think it would be better to choose the GUA rather than the
dissimilar ULA, absent some policy to the contrary.

On Tue, Dec 21, 2021 at 9:18 AM Chengli (Cheng Li) <[email-masked]> wrote:

> Yes, I mean if we only have ULA, then the source address selection MUST
> choose ULA, so issues come.  Unless we have multiple address configured.
>
>
>
>
>
>
>
> *Sent:* Tuesday, December 21, 2021 10:17 PM

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 22 Dec 2021 03:24:56 +0000

Well, I may need to state it more clear. Copy v6ops as well.

The topology is shown below.

           |------------|           |-----------|
H1---|      SP1       |-------|    SP2       |-----H2
          |                     |           |                  |
          --------------|           |-----------|

The packet P1 is sent from H1 to H2, and the source address is a GUA like 2001:db8:1:1::1, and the DA is a GUA of H2 2001:db8:2:2::2.  So P1 =  (2001:db8:1:1::1, 2001:db8:2:2::2)

The route to H2 has been learnt by nodes in SP1 and SP2. But in SP2 network, they are using ULA for infrastructure address, like interface address or loopback address. Note that no GUA is configured for infrastructure.

The packet P1 is forwarding in SP2 network, and the route is a GUA route to H2. When an error occurs in forwarding ,for instance a node can not process the Extension header of P1, or the size of P1 exceeds the PMTU in that link, an ICMP message will be sent back to the SA of P1, which is 2002:db8:1:1::1, if these is a native IPv6 forwarding without tunnel. Then in this case, what source address of the ICMP packet will use? I guess it MUST be an ULA address of that node? So an ICMP packet (ULA_SA, 2001:db8:1:1::1)/ICMP payload is expected to send back to the H1.

So ULA of SP2 will be leaked outside the domain SP2 in this way? Or the edge node of SP2 will drop the ICMP packet and the H1 will not know why the packet is lost?

But my understanding may be wrong,  just  for discussion.

Respect,
Cheng

Sent: Wednesday, December 22, 2021 2:38 AM

The problem is that in your example, a packet came _from_ the internet (or at least a GUA) _to_ your ULA. That's not possible unless routing is working, but if it does happen, the GUA is reachable, so presumably either the ULA sourced packet will get to the GUA, or it will be dropped somewhere along the path. But it can't have come from a GUA unless there was a route to the ULA. If you are thinking of configuring routers that route packets from/to the internet with ULAs only, don't do that—it's not a valid configuration.

The issue I'm pointing to is similar, but the problem is that both links have a ULA, but only one link has a route to the other link's ULA, whereas the other link has only a route to the GUA. And source address selection winds up choosing the (non-routable) ULA as a source address because it's a ULA, not because it matches the other ULA in any meaningful way. In this case I think it would be better to choose the GUA rather than the dissimilar ULA, absent some policy to the contrary.

On Tue, Dec 21, 2021 at 9:18 AM Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>> wrote:
Yes, I mean if we only have ULA, then the source address selection MUST choose ULA, so issues come.  Unless we have multiple address configured.

Respect,
Cheng

Respect,
Cheng

Exactly.

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Tue, 21 Dec 2021 19:48:46 -0800

For what it’s worth, lots of providers’ IPv4 networks leak RFC1918 addresses in this way to their subscribers, so for example on Wave in the US you will often see traceroutes full of addresses in 10/8.

I wonder if the discussion of how to handle this use case has happened in IPv4 already?  It appears at first blush that replacing the address with a GUA from the edge when it transits out of the ULA-using network would help, though it might be misleading when routes are asymmetric.

> On Dec 21, 2021, at 7:26 PM, Chengli (Cheng Li) <c.l=[email-masked]> wrote:
> 
> 
> Therefore, a (ULA_SA, A) packet is sent back to the address A, in this way the source address ULA_SA is leaked.  We can avoid this by dropping  the packet (ULA_SA, A) at the edge node, then the source node will not have the idea of why my packet is lost L.
>  
> On Sun, Dec 12, 2021 at 4:06 PM Michael Richardson <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Dec 2021 16:49:50 +1300

Hi Cheng,

It would help to use a fixed-width font for ASCII art ;-)

The same problem has been seen with networks that use
link-local addresses between routers. Neither LL nor ULA
should be used as the source of ICMPv6 messages. I'm pretty
sure that is written down somewhere, but I forget where.
(For LL, it's mentioned in RFC7404, but that isn't normative.)

Doesn't https://datatracker.ietf.org/doc/html/rfc4193#section-4.3
mean the ICMPv6 packet itself would be dropped?

Regards
    Brian

On 22-Dec-21 16:24, Chengli (Cheng Li) wrote:
> The packet P1 is forwarding in SP2 network, and the route is a GUA route to H2. When an error occurs in forwarding ,for instance a node can not process the Extension header of P1, or the size of P1 exceeds the PMTU in 
that link, an ICMP message will be sent back to the SA of P1, which is 2002:db8:1:1::1, if these is a native IPv6 forwarding without tunnel. Then in this case, what source address of the ICMP packet will use? I guess it 
MUST be an ULA address of that node? So an ICMP packet (ULA_SA, 2001:db8:1:1::1)/ICMP payload is expected to send back to the H1.
> 
> So ULA of SP2 will be leaked outside the domain SP2 in this way? Or the 
edge node of SP2 will drop the ICMP packet and the H1 will not know why the packet is lost?
> The problem is that in your example, a packet came _from_ the internet (or at least a GUA) _to_ your ULA. That's not possible unless routing is working, but if it does happen, the GUA is reachable, so presumably either the ULA sourced packet will get to the GUA, or it will be dropped somewhere along the path. But it can't have come from a GUA unless there was a 
route to the ULA. If you are thinking of configuring routers that route packets from/to the internet with ULAs only, don't do that—it's not a valid configuration.
> So I think ULA can be used ONLY in an ISOLATED network, where the ULA route/address will not be leaked outside the domain. The isolated means we 
> Do you mean because the two routers have no knowledge of the ULA on network A, they would send the ICMP response in the wrong direction? I think 
in this case R1 would have an address on the ULA prefix on its interface on network A, so that wouldn't be a problem. An ICMP port unreachable from H1 would not reach a host on network A, however, so you are correct about that. But I don't think it really changes the problem.
> Maybe. Or maybe the operator configured it to provide a ULA. I don't think it matters for digging into this question. I think it's valid for the 
> No worries. I don't entirely agree, but I do agree that it's important to evaluate whether this is a plausible scenario. The question I'm asking 
arose as a result of something that I think was a bug, so I am not convinced that examining the /exact/ scenario closely adds a lot of value. The question is whether we believe this could happen IRL with things that aren't buggy (I have an example of how it could happen), whether we want to mitigate this problem, and whether my proposed mitigation is the right one.

---

From: Gert Doering <[email-masked]>
Date: Wed, 22 Dec 2021 08:13:49 +0100

HI,

> The route to H2 has been learnt by nodes in SP1 and SP2. But in SP2 network, they are using ULA for infrastructure address, like interface address or loopback address. Note that no GUA is configure…

This is a scenario that is bound to create lots of problems, and solve
nothing.  So, just don't do this.

In RIPE land, RIPE members can request an extra IPv6 PI /48 for their 
transport infrastructure - which does not need to be announced to BGP, so 
the effect "my infrastructure is not routed from the outside" can be 
achieved, but GUAs with full reverse DNS and working ICMP are still 
available.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 22 Dec 2021 09:19:08 +0000

Hi Brain,

Thank you for your reminding.  :) will do next time.

Agree with your comment of " Neither LL nor ULA should be used as the source of ICMPv6 messages." . 

Does it mean we CANNOT ONLY configure LLA or ULA for infrastructure? We still need to configure other type of address, like GUA? 

Cheng

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, December 22, 2021 11:50 AM
To: Chengli (Cheng Li) <[email-masked]>; Ted Lemon <[email-masked]>
Cc: Michael Richardson <[email-masked]>; IPv6 Ops WG <[email-masked]>; [email-masked]
Subject: Re: Possible issue with source address selection for ULAs...

Hi Cheng,

The same problem has been seen with networks that use link-local addresses between routers. Neither LL nor ULA should be used as the source of ICMPv6 messages. I'm pretty sure that is written down somewhere, but I forget where.
(For LL, it's mentioned in RFC7404, but that isn't normative.)

Regards
    Brian

On 22-Dec-21 16:24, Chengli (Cheng Li) wrote:
> The packet P1 is sent from H1 to H2, and the source address is a GUA 
> like 2001:db8:1:1::1, and the DA is a GUA of H2 2001:db8:2:2::2.  So 
> P1 =
 (2001:db8:1:1::1, 2001:db8:2:2::2)
> The packet P1 is forwarding in SP2 network, and the route is a GUA 
> route to H2. When an error occurs in forwarding ,for instance a node 
> can not process the Extension header of P1, or the size of P1 exceeds 
> the PMTU in
that link, an ICMP message will be sent back to the SA of P1, which is 2002:db8:1:1::1, if these is a native IPv6 forwarding without tunnel. Then in this case, what source address of the ICMP packet will use? I guess it MUST be an ULA address of that node? So an ICMP packet (ULA_SA, 2001:db8:1:1::1)/ICMP payload is expected to send back to the H1.
> The problem is that in your example, a packet came _from_ the internet 
> (or at least a GUA) _to_ your ULA. That's not possible unless routing 
> is working, but if it does happen, the GUA is reachable, so presumably 
> either the ULA sourced packet will get to the GUA, or it will be 
> dropped somewhere along the path. But it can't have come from a GUA 
> unless there was a
> Cc: Michael Richardson 
> <[email-masked]<mailto:[email-masked]>>; 
> Cc: Michael Richardson 
> <[email-masked]<mailto:[email-masked]>>; 
> think
> From: ipv6 
> [mailto:[email-masked]<mailto:[email-masked]>]
On Behalf Of Ted Lemon
> To: Michael Richardson 
> <[email-masked]<mailto:[email-masked]>>
> Does the R1 router for A have a ULA prefix? Or a GUA prefix that it 
> got
from W?
> This does seems reasonable given race conditions, hidden node issues 
> with wifi, flaky wiring, flaky power, ...
> 
> Exactly.
> 
> 
>      > router, but it's not wrong behavior for a router. It's 
> perfectly
valid for
> Maybe. Or maybe the operator configured it to provide a ULA. I don't 
> think it matters for digging into this question. I think it's valid 
> for the
>      > rather that the situation that we found ourselves in as a 
> result
of the
> I'm gonna try to get the assumption right before I try to understand 
> the situation in which things fail. :-)
> 
> No worries. I don't entirely agree, but I do agree that it's important 
> to evaluate whether this is a plausible scenario. The question I'm 
> asking

---

From: Gert Doering <[email-masked]>
Date: Wed, 22 Dec 2021 10:36:43 +0100

Hi,

> Does it mean we CANNOT ONLY configure LLA or ULA for infrastructure? We still need to configure other type of address, like GUA? 

If you use LLA your equipment needs to have at least one GUA and 
do proper source address selection for outgoing ICMPs - I'd expect
gear to get that part right, because "do not send packets with a LLA
source off-link" has been part of the standards since day 1.

If you want to use ULA, you need to speak to your vendors to ensure
that your gear gets source address selection right, and will send
ICMPs "off-net" from a GUA address.  If your equipment cannot do that,
you can not use ULAs for this purpose.

Gert Doering
        -- NetMaster

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 22 Dec 2021 09:50:48 +0000

Hi Gert, 

Agree with don't do that. 

I support to use GUA and avoid to use ULA in operator's network, especially for the infrastructure. It will avoid many risks and complexities, and make the network better. 
As far as I know, most (95+%?) operators use GUA in their network. Luckily,  people are smart on this.

Thank you for your reply!

Respect,
Cheng

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Wednesday, December 22, 2021 3:14 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: Ted Lemon <[email-masked]>; Michael Richardson <[email-masked]>; IPv6 Ops WG <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

HI,

> The route to H2 has been learnt by nodes in SP1 and SP2. But in SP2 network, they are using ULA for infrastructure address, like interface address or loopback address. Note that no GUA is configure…

This is a scenario that is bound to create lots of problems, and solve nothing.  So, just don't do this.

In RIPE land, RIPE members can request an extra IPv6 PI /48 for their transport infrastructure - which does not need to be announced to BGP, so the effect "my infrastructure is not routed from the outside" can be achieved, but GUAs with full reverse DNS and working ICMP are still available.

Gert Doering
        -- NetMaster

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 22 Dec 2021 10:11:11 +0000

Agree with your POV. Using GUA can avoid the mess troubles I think. Thank you again!

Respect,
Cheng

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Wednesday, December 22, 2021 5:37 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Ted Lemon <[email-masked]>; Michael Richardson <[email-masked]>; IPv6 Ops WG <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

Hi,

> Does it mean we CANNOT ONLY configure LLA or ULA for infrastructure? We still need to configure other type of address, like GUA? 

If you use LLA your equipment needs to have at least one GUA and do proper source address selection for outgoing ICMPs - I'd expect gear to get that part right, because "do not send packets with a LLA source off-link" has been part of the standards since day 1.

If you want to use ULA, you need to speak to your vendors to ensure that your gear gets source address selection right, and will send ICMPs "off-net" from a GUA address.  If your equipment cannot do that, you can not use ULAs for this purpose.

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Wed, 22 Dec 2021 12:37:02 +0100

Brian,

> (For LL, it's mentioned in RFC7404, but that isn't normative.)

RFC4443:
      the Source Address of the ICMPv6 packet MUST be a unicast address
      belonging to the node.  The address SHOULD be chosen according to
      the rules that would be used to select the source address for any
      other packet originated by the node, given the destination address
      of the packet.  However, it MAY be selected in an alternative way
      if this would lead to a more informative choice of address
      reachable from the destination of the ICMPv6 packet.

Any unicast address within the above recommendations are fine, including ULA and LL SAs.

An implementor obviously has to get it right(tm), and there are plenty of sharks in these waters.

O.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Dec 2021 10:05:59 +1300

> An implementor obviously has to get it right(tm), and there are plenty of sharks in these waters.

Yes. But RFC7404 did try to get it right for the link-local case, and I don't see why the recommendation for ULA would be different. I do agree that a transit network should have a GUA prefix, regardless of choosing to use LLAs or GUAs for its own private purposes.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Dec 2021 17:33:01 -0500

What utility would  a ULA have for a router that also has a GUA?

On Wed, Dec 22, 2021 at 16:06 Brian E Carpenter <[email-masked]>
wrote:

> Yes. But RFC7404 did try to get it right for the link-local case, and I
> don't see why the recommendation for ULA would be different. I do agree
> that a transit network should have a GUA prefix, regardless of choosing to
> use LLAs or GUAs for its own private purposes.
>
>     Brian
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Dec 2021 11:51:50 +1300

> What utility would  a ULA have for a router that also has a GUA?

I don't know, and don't actually care either. It would be the
operator's private business as long as they never leak such
addresses.

    Brian
> 
> On Wed, Dec 22, 2021 at 16:06 Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On 23-Dec-21 00:37, [email-masked] <mailto:[email-masked]> wrote:
>      > Brian,
>      >

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Dec 2021 09:51:43 +1100

>       reachable from the destination of the ICMPv6 packet.

Which I think is is a long way of saying RFC6724 default address selection.

You can see nodes using SA selection for ICMPv6 using the following
multicast ping command on a Linux box (using ping from 'iputils'
because it might matter):

ping -I <ULA or GUA interface address> ff02::1%<interface name>

If you just do this, you get LLA source address responses, because
default address selection picks the interface LLA as the SA:

ping ff02::1%<interface name>

One interesting thing is that some of my IPv6 nodes respond to this
with their Link-Local Address, rather than a ULA or GUA address. I
don't know which specific devices they are, however going by MAC
address OUIs, they're Google devices.

I'm guessing IPv6 on them has been "disabled" by not listening to RAs,
so they don't get a ULA or GUA address. They respond with a LLA source
address due to picking the smallest matching SA scope for the DA (ULA
or GUA), and that is the LLA address it does have.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Dec 2021 10:06:01 +1100

> operator's private business as long as they never leak such

GUA renumbering can happen in SP networks. It's more likely to be
shifting address space around than replacing a GUA RIR prefix with
another one. ULA would effectively be the "out of band" addressing and
access to remotely access these routers while renumbering their GUA
space this.

Another use is to protect internal services such as DHCPv6 servers,
RADIUS etc. from DDoS attacks from the Internet and customers (e.g.
DHCPv6 traffic between a BNG and a DHCPv6 server doesn't need to be
GUA - the DHCPv6 server might have a different link to the network
with a GUA for management and updates). DDoS traffic can't be sent
from the Internet to internal ULA addresses. Customers' CPE should
drop packets to ULA DAs launching a DDoS, however just in case that
doesn't work, and the traffic follows CPE default routes, customers
should also have DA filters applied to their traffic limiting to the
GUA Internet space and LLA for local protocols like DHCPv6-PD on the
WAN.

Regards,
Mark.

---

From: "Soini, Jyrki" <[email-masked]>
Date: Thu, 23 Dec 2021 07:05:14 +0000

> You can see nodes using SA selection for ICMPv6 using the following multicast ping command on a Linux box (using ping from 'iputils'
> If you just do this, you get LLA source address responses, because default address selection picks the interface LLA as the SA:
>
> One interesting thing is that some of my IPv6 nodes respond to this with their Link-Local Address, rather than a ULA or GUA address. I don't know which specific devices they are, however going by MAC address OUIs, they're Google devices.
>
> I'm guessing IPv6 on them has been "disabled" by not listening to RAs, so they don't get a ULA or GUA address. They respond with a LLA source address due to picking the smallest matching SA scope for the DA (ULA or GUA), and that is the LLA address it does > have.
>
> Regards,
> Mark.

In this case ping destination  ff02::1 is link-local-scope multicast address, which is on link.

RFC6724 Default Address Selection for Internet Protocol Version 6 (IPv6):

3.1.  Scope Comparisons

   Multicast destination addresses have a 4-bit scope field that
   controls the propagation of the multicast packet.  The IPv6
   addressing architecture defines scope field values for interface-
   local (0x1), link-local (0x2), admin-local (0x4), site-local (0x5),
   organization-local (0x8), and global (0xE) scopes (Section 2.7 of
   [RFC4291]).

   Use of the source address selection algorithm in the presence of
   multicast destination addresses requires the comparison of a unicast
   address scope with a multicast address scope.  We map unicast link-
   local to multicast link-local, unicast site-local to multicast site-
   local, and unicast global scope to multicast global scope.
...
5.  Source Address Selection
...
Rule 1: Prefer same address.
   If SA = D, then prefer SA.  Similarly, if SB = D, then prefer SB.

   Rule 2: Prefer appropriate scope.
   If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
   otherwise prefer SA.  Similarly, if Scope(SB) < Scope(SA): If
   Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.

      Discussion: This rule must be given high priority because it can
      affect interoperability.

IMHO, responses with link-local address is expected behaviour. Nodes that respond with ULA or GUA to ff02::1 are not following RFC6724 rules.
--
Jyrki

This email may contain information which is privileged or protected against unauthorized disclosure or communication. If you are not the intended recipient, please notify the sender and delete this message and any attachments from your system without producing, distributing or retaining copies thereof or disclosing its contents to any other person.

Telia Company processes emails and other files that may contain personal data in accordance with Telia Company’s Privacy Policy<https://www.teliacompany.com/en/about-the-company/privacy/>.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 23 Dec 2021 14:15:44 +0100

> Does it mean we CANNOT ONLY configure LLA or ULA for infrastructure? We still need to configure other type of address, like GUA? 

Dear Cheng,

In rare occasions I've seen ISPs running their infrastructure on LLs with GUA
addresses on loopbacks, but then their gear needs to get
source-address-selection right. Many of those who started with LL for
infrastructure then added GUAs to the interfaces to make their troubleshooting
tools more efficient and traceroute output more meaningful.

If it can be done with LL - it doesn't mean that it should be done, so my
preference goes towards GUA. I'll not even comment on "ULA for infrastructure"
as that's a clear rathole :)

Cheers, Jan Zorz

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 24 Dec 2021 02:45:15 +0000

Agree, and thank you for you reply. It is good to learn more about IPv6, especially from the deployment  :)

Respect,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Jan Zorz - Go6
Sent: Thursday, December 23, 2021 9:16 PM
To: [email-masked]
Subject: Re: Possible issue with source address selection for ULAs...

Dear Cheng,

In rare occasions I've seen ISPs running their infrastructure on LLs with GUA addresses on loopbacks, but then their gear needs to get source-address-selection right. Many of those who started with LL for infrastructure then added GUAs to the interfaces to make their troubleshooting tools more efficient and traceroute output more meaningful.

If it can be done with LL - it doesn't mean that it should be done, so my preference goes towards GUA. I'll not even comment on "ULA for infrastructure"
as that's a clear rathole :)

Cheers, Jan Zorz

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 24 Dec 2021 04:40:20 +0000

Oh Brain,  I reread the https://datatracker.ietf.org/doc/html/rfc4193#section-4.6

It seems like this has been stated explicitly. See below.

"""
        Nodes that can communicate with other nodes inside of the site
        and outside of the site: These nodes should autoconfigure global
        addresses via [ADDAUTO] or receive global address via [DHCP6].
        They may also obtain Local IPv6 addresses via the same
        mechanisms.
"""

Thank you for your help and Merry Christmas!
Cheng

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, December 23, 2021 6:52 AM
To: Ted Lemon <[email-masked]>
Cc: 6man WG <[email-masked]>; Chengli (Cheng Li) <[email-masked]>; IPv6 Ops WG <[email-masked]>; Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

> What utility would  a ULA have for a router that also has a GUA?

I don't know, and don't actually care either. It would be the operator's private business as long as they never leak such addresses.

    Brian