Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-02.txt

[Vasilenko Eduard <[e-mail]>]

Hi Mark,
Sorry, I made a mistake in the terminology in this message: “Next hop” instead of “destination address”.
The destination address is first, then should be the source address selection, and only then the next hop.
Now it is the wrong chain: destination -> next hop -> source.
Eduard
From: Vasilenko Eduard
Sent: Monday, October 23, 2023 11:59 AM
To: 'Mark Smith' <[e-mail]>
Cc: Brian E Carpenter <[e-mail]>; David Farmer <[e-mail]>; 6man WG <[e-mail]>
Subject: RE: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-02.txt

https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-support-mhmp-02#page-8
Discusses 7 methods (numbered 1-7). Some historical and very bad. The list could be expanded.
Ed/
From: Mark Smith [mailto:[e-mail]]
Sent: Monday, October 23, 2023 11:51 AM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: Brian E Carpenter <[e-mail]<mailto:[e-mail]>>; David Farmer <[e-mail]<mailto:[e-mail]>>; 6man WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-02.txt


On Mon, 23 Oct 2023, 19:43 Vasilenko Eduard, <[e-mail]<mailto:[e-mail]>> wrote:
> Sorry to repeat myself, but IMHO we can *only* fix it by replacing the whole
> mechanism (RFC3485/6724 and getaddrinfo). The bug is trying to pick a
> destination address instead of picking an address pair. (Kudos to Eduard
> Vasilenko for pointing this out a few months ago.)

But my solution was different:
a) change the order of address choices: source address should be chosen first (destination later)

How can you choose a source address when you don't know what the destination is?

The only SA that *might* work in all cases without knowing a DA is a GUA, making LLAs and ULAs entirely useless.

b) then enjoy RFC 8028 which has enough corrections to get PA multi-homing to work.
Unfortunately, the above solution is only for multi-homing.
NAT presence/absence would still have challenges - it is a different problem.
Of course, it is possible to fix it by a separate flag (and PIO for this flag).

I do not have objections against Brian's proposal to scrape RFC 6724 completely and propose address pairs sorting.
However, only the second problem is in the discussion yet (how to understand when ULA is NATed or not).
The PA multi-homing for "address pairs sorting" is not discussed yet.
Eduard
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Brian E Carpenter
> Sent: Saturday, October 21, 2023 10:53 PM
> To: David Farmer <[e-mail]<mailto:[e-mail]>>; Mark Smith
> <[e-mail]<mailto:[e-mail]>>
> Cc: 6man WG <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-02.txt
>
> On 22-Oct-23 06:07, David Farmer wrote:
> >
> > On Sat, Oct 21, 2023 at 3:51 AM Mark Smith <[e-mail]<mailto:[e-mail]>
> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
> >
> >
> >     On Sat, 21 Oct 2023, 13:49 David Farmer,
> <farmer=[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
> wrote:
> >
> >
> >         4. I've been rethinking Section 7. Maybe it shouldn't refer to RFC5220
> and should focus the section simply on the problem of "ULA Source with GUA
> Destination."
> >
> >
> >             7. ULA Source with GUA Destination
> >
> >             A problematic situation exists when only a ULA source is available for
> communication with a GUA destination. Since only having a ULA source
> generally implies only local connectivity is available, with no connectivity to
> the IPv6 Internet.
> >
> >
> >     I don't agree with this. It means that all local network hosts must have
> ULA addresses to be reachable from other internal hosts over IPv6.
> >
> >     If an internal host has a GUA address and another host has a ULA
> address, and the local network's routing system/routes can provide a
> bidirectional path been them, why shouldn't it work?
> >
> >
> > Ok, I see what you are saying. But what is the remedy?
> >
> > Is the problem the Prefer Matching Label Rule altogether, or is it the
> separate label for ULA from GUA?
> >
> > Rule 5 of Section 6 isn't new; It goes back to RFC3484. Also, the separate
> label is new; At least for site-local, it goes back to RFC 3484 as well. There was
> the same situation between site-local and GUA, but it was created by Rule 2
> of Section 6, prefer matching scope since site-local was a separate
> scope. Anyway, IPv4 would have been preferred to a site-local source and a
> GUA destination, and vice versa.
> >
> >     This hasn't been the case with IPv4, so I think this would be unexpected
> behaviour in IPv6. RFC1918 addressed hosts have been able to reach
> internally publically addressed hosts as long as the routing system has the
> routes to provide the bidirectional path between them.
> >
> >
> > Actually, if there were only the IPv6 stack, the rules would provide the
> same behavior as IPv4. The problem is dual-stack, and that IPv4 provides
> another option. So, maybe the problem is mixing IPv6 and IPv4 and trying to
> choose between them in the policy table. Maybe the answer is to remove
> IPv4 (::ffff:0:0/96) from the IPv6 policy table and only use Happy Eyeballs to
> choose between IPv6 and IPv4.
> >
> >     Below seems to me to be another example of trying to build too much
> intelligence about dynamic network reachability into a static table starting
> point in hosts.
> >
> >     The only way to reliably determine if connectivity exists is to attempt it,
> which is why RFC3484/6724 say to attempt each DA provided by
> getaddrinfo() until one works or they've all failed.
> >
> >     There will never be a RFC6724 table that can ensure the first DA returned
> by getaddrinfo() is the one that always works.
> >
> >     (If there was then getaddrinfo() would only ever need to return one DA,
> and we wouldn't have dynamic routing, links would be 100% reliable, there
> would be no packet loss and no need to retransmissions to recover from
> them, nor any need for checksums because packets would never get
> corrupted.)
> >
> >     Regards,
> >     Mark.
> >
> >
> >             In such cases, it is likely better to use IPv4 if it is available. This
> section discusses several complementary mechanisms available to achieve
> this outcome.
> >
> >             7.1 Prefer Matching Label Rule
> >
> >             RFC 6724 added a separate label for ULA (fc00::/7), whose
> precedence is raised by this update. This separate label interacts with Rule 5
> of Section 6 of RFC 6724, which says;
> >
> >                 Rule 5: Prefer matching label.
> >
> >                 If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <>
> Label(DB), then prefer DA.  Similarly, if Label(Source(DA)) <> Label(DA)
> and Label(Source(DB)) = Label(DB), then prefer DB.
> >
> >
> >             In this case, the ULA source label will not match the GUA destination
> label, and therefore, an IPv4 destination will be selected over a GUA
> destination with a ULA source, even though ULA has a higher precedence
> than IPv4 in the policy table.
> >
> >
> > So, how do we fix it?
>
> Sorry to repeat myself, but IMHO we can *only* fix it by replacing the whole
> mechanism (RFC3485/6724 and getaddrinfo). The bug is trying to pick a
> destination address instead of picking an address pair. (Kudos to Eduard
> Vasilenko for pointing this out a few months ago.)
>
> For the specific sub-problem of ULA<==>GUA, see the last line of Nick's latest
> message.
>
>     Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]<mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------