Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

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

From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, December 22, 2021 2:38 AM
To: Chengli (Cheng Li) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: Possible issue with source address selection for ULAs...

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.

From: Ted Lemon [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 21, 2021 10:17 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...

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,

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

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,

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

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

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

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

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

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

Exactly.

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

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.

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

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.

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: 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:
> 
> 
> On Tue, Dec 21, 2021 at 9:18 AM Chengli (Cheng Li) <[email-masked]> wrote:
> On Tue, Dec 21, 2021 at 09:01 Chengli (Cheng Li) <[email-masked]> wrote:
> Hi Ted,
>  
> 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 Tue, Dec 21, 2021 at 3:57 AM Chengli (Cheng Li) <[email-masked]> wrote:
> Hi Ted,
>  
> From: ipv6 [mailto:[email-masked]] On Behalf Of Ted Lemon
> To: Michael Richardson <[email-masked]>
> Cc: [email-masked]
> 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.
> 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.
> 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.
> 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 
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.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

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]>>; 
> [email-masked]<mailto:[email-masked]>
> 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
> Cc: Michael Richardson 
> <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]<mailto:[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
> 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: "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