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

["Chengli (Cheng Li)" <[e-mail]>]

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:[e-mail]]
Sent: Wednesday, December 22, 2021 2:38 AM
To: Chengli (Cheng Li) <[e-mail]>
Cc: Michael Richardson <[e-mail]>; [e-mail]
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) <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, December 21, 2021 10:17 PM
To: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>
Cc: Michael Richardson <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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) <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, December 21, 2021 9:18 PM
To: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>
Cc: Michael Richardson <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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) <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Ted Lemon
Sent: Monday, December 13, 2021 8:22 PM
To: Michael Richardson <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Possible issue with source address selection for ULAs...

On Sun, Dec 12, 2021 at 4:06 PM Michael Richardson <[e-mail]<mailto:[e-mail]>> 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.