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

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

That is what I understand as well, so how to know the reason of why the packet is dropped? And where?

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

I think most SPs will drop these packets with ACL or uRPF at the ASBR/edge。

发件人: v6ops <[email-masked]<mailto:[email-masked]>> 代表 "Chengli (Cheng Li)" <c.l=[email-masked]<mailto:c.l=[email-masked]>>
日期: 2021年12月22日 星期三 上午11:24
收件人: Ted Lemon <[email-masked]<mailto:[email-masked]>>
抄送: Michael Richardson <[email-masked]<mailto:[email-masked]>>, IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
主题: Re: [v6ops] Possible issue with source address selection for ULAs...

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

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.
_______________________________________________ v6ops mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops
如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除<mailto:[email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除>。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked]<mailto:[email-masked]> ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Dec 2021 09:13:08 -0500

If you want your IPv6 transit network to work, do not number the interfaces
of the routers with ULAs. As you say, lots of things will break if you
violate this rule.

I don’t think we need to fix this—there isn’t a shortage of IPv6 addresses.
The reason to use a ULA is when you need one or more prefixes but don’t
have a way to get them from an internet connection.

On Wed, Dec 22, 2021 at 04:20 Chengli (Cheng Li) <[email-masked]> wrote:

> *From:* strong [mailto:[email-masked]]
> *Sent:* Wednesday, December 22, 2021 2:20 PM
> *To:* Chengli (Cheng Li) <[email-masked]>; Ted Lemon <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>; IPv6 Ops WG <
> [email-masked]>; [email-masked]
> *Subject:* Re: [v6ops] Possible issue with source address selection for
> ULAs...
>
>
>
> *发件人**: *v6ops <[email-masked]> 代表 "Chengli (Cheng Li)" <
> c.l=[email-masked]>
> *日期**: *2021年12月22日 星期三 上午11:24
> *收件人**: *Ted Lemon <[email-masked]>
> *抄送**: *Michael Richardson <[email-masked]>, IPv6 Ops WG <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *主题**: *Re: [v6ops] Possible issue with source address selection for
> ULAs...
>
>
>
> 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?
>
>
>
> *From:* Ted Lemon [mailto:[email-masked] <[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]> 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]]
> *Sent:* Tuesday, December 21, 2021 10:17 PM
> *To:* Chengli (Cheng Li) <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>; [email-masked]
> *Subject:* Re: Possible issue with source address selection for ULAs...
>
>
>
> On Tue, Dec 21, 2021 at 09:01 Chengli (Cheng Li) <[email-masked]> wrote:
>
> Hi Ted,
>
>
>
> 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]
> *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]> 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...
>
>
>
> On Sun, Dec 12, 2021 at 4:06 PM Michael Richardson <[email-masked]>
> wrote:
>
> 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.
>
>
>
> 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
> 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.
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
> 如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]
> ，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error
> please notify us immediately by e-mail. Please reply to
> [email-masked] ,you can unsubscribe from this mail. We will
> immediately remove your information from send catalogue of our.
>

---

From: [email-masked]
Date: Wed, 22 Dec 2021 15:36:33 +0100

Ted,

> If you want your IPv6 transit network to work, do not number the interfaces of the routers with ULAs. As you say, lots of things will break if you violate this rule. 

This is how myths spread. Please stop.
Routers use the weak host model.
Using link-locals only on an interface works just fine according to our RFCs.

> I don’t think we need to fix this—there isn’t a shortage of IPv6 addresses. The reason to use a ULA is when you need one or more prefixes but don’t have a way to get them from an internet connection. 

O.

---

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

You might notice that I said ULAs, not link-locals. :)

That said, do you think there's a use case for ULAs here? I think there is
not, but I'm certainly open to hearing your reasons to the contrary.

On Wed, Dec 22, 2021 at 9:36 AM <[email-masked]> wrote:

> Ted,
>
> > If you want your IPv6 transit network to work, do not number the
> interfaces of the routers with ULAs. As you say, lots of things will break
> if you violate this rule.
>
> > I don’t think we need to fix this—there isn’t a shortage of IPv6
> addresses. The reason to use a ULA is when you need one or more prefixes
> but don’t have a way to get them from an internet connection.
>
> O.
>
>

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 24 Dec 2021 10:09:57 -0800

> I think most SPs will drop these packets with ACL or uRPF at the 
certainly in our line of work fc00::/7 is part of a responsible martian 
edge acl set.

one could conceive of allowing it exclusively for ICMP but in general 
that seems inconsistent with both an antispoofing posture and rfc 
rfc4193's recommendation that default behavior be to reject import and 
export of fc00/7 prefixes.

joel