RE: RFC6724-bis?

[Vasilenko Eduard <[e-mail]>]

I hope ULA in public DNS is not pointing to Google or something big. Then why is it a problem if ULA is advertised for abcd.efgh.klmno.com?
It is a problem only for this resource. Good luck to them.

It would not be a problem for another organization till the organization would increase precedence for FC/7 above GUA.

Moreover, it is not a problem for another organization till the organization would not activate ULA PIO inside,

Because Rule 5: Prefer matching label would prefer GUA despite ULA and GUA received in the DNS.

If no PIO – nothing to match for the source even if FC/7 is already the highest precedence.



And only if the organization would activate ULA PIO, change FC/7 preference above GUA, and somebody requests abcd.efgh.klmno.com– then would be a problem.

It looks pretty artificial situation.

Then TCP would not receive ACK. In 300ms (old style HYv1) host would switch to IPv4.
HYv2 is faster (50ms) but supported only by Apple.

Ed/
From: David Farmer [mailto:farmer=[e-mail]]
Sent: Thursday, September 22, 2022 8:21 PM
To: Vasilenko Eduard <[e-mail]>
Cc: 6man WG <[e-mail]>; Ted Lemon <[e-mail]>
Subject: Re: RFC6724-bis?

Experience has shown us that despite recommendations to the contrary, ULAs are in the Public DNS, how much is questionable, but it exists nonetheless.

Further, using the converse to the argument that address collisions are a very low probability event, if ULA prefixes are randomly selected, as recommended in RFC 4193; therefore, any such randomly selected ULA prefix learned from the DNS is going to have a very high probability that it is unreachable. This is why, we shouldn’t prefer ULA address unless there is knowledge the ULA prefix is actually locally connected.

It’s worth repeating, unless a ULA prefix is know to be locally connected, there is a very high probability that any connections to it will simply fail.

Now I have some related questions, is this connection failure going to result in a full TCP timeout or happy eyeballs timer expiring? Or, will an ICMP destination unreachable or other ICMP message shortcut the TCP timeout or the happy eyeballs timer? Will most CPEs on the market generate an ICMP destination unreachable, an ICMP administratively disallowed, or simply just forward the packet to the upstream ISP using the default route? Would most ISPs generate an ICMP destination unreachable for the ULA in this case? Finally, even if the ISP’s router generates the ICMP destination unreachable, in most cases, I don’t believe the ISP will have a route back to the originating ULA address anyway.

So, I think we are probably better off with SA/DA selection not preferring ULA unless the prefix is know to be local.  This is the best guess.

Thanks.

On Thu, Sep 22, 2022 at 11:05 Vasilenko Eduard <vasilenko.eduard=[e-mail]<mailto:[e-mail]>> wrote:
I hope DNS advertising ULA is not foreign. Problem solved.
If the organization is using many ULA prefixes – they should be distributed everywhere,
Or DNS should announce different views for different company regions.

You are looking for the solution for the configuration inconsistency: DNS has announced something but routing is not available.
Ed/
From: Ted Lemon [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, September 22, 2022 6:54 PM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: Mark Smith <[e-mail]<mailto:[e-mail]>>; 6man WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: RFC6724-bis?

If I have a GUA and no ULA, and I get a ULA, I'm going to guess that I should use the GUA because I have no choice. If I have a GUA and a ULA, and I see a foreign ULA, longest match will choose the ULA, not the GUA, but there is no guarantee that the ULA is reachable from the foreign ULA. So no, longest match isn't actually going to reliably guess right here. Practically speaking, in this case using the GUA is always better, because even if my ULA happens to be reachable from the device with the foreign ULA, the GUA will still also work.

On Thu, Sep 22, 2022 at 11:50 AM Vasilenko Eduard <[e-mail]<mailto:[e-mail]>> wrote:
The longest match helps to choose what is local
It is rule 8 in RFC 6724.
Already works.
Ed/
From: ipv6 [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Ted Lemon
Sent: Thursday, September 22, 2022 6:35 PM
To: Mark Smith <[e-mail]<mailto:[e-mail]>>
Cc: 6man WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: RFC6724-bis?

Still, a local ULA can be presumed reachable, whereas a ULA that is not configured locally may or may not be reachable. Ideally we want to try the thing that will work first. And we’ve actually seen non-local ULAs fail in the wild. So while doing happy eyeballs is a great way to avoid failing when your best guess is wrong, making better guesses is still good.

Op do 22 sep. 2022 om 11:30 schreef Mark Smith <[e-mail]<mailto:[e-mail]>>

On Thu, 22 Sept 2022, 20:38 Ted Lemon, <[e-mail]<mailto:[e-mail]>> wrote:
Wouldn’t increasing the ULA priority have the problem that we’d get longest match wins on alien ULAs though?  I think that was why the “add local ULAs to the table” rule was originally proposed.

Why is do people think the static default DA/SA selection will always accurately choose the best outcome for a dynamic network?

The set of answers from DA/SA selection are supposed to be tested until one of them succeeds.

A ULA response in a DNS RR should be the best answer most of the time, however sometimes the alternative GUA will be better and be successful.

That is, try the ULA destination, and if that fails, try the GUA DA, when both are provided in a DNS response.

A static algorithm like default DA/SA selection is sometimes going to be wrong when being applied to a dynamic situation.

Regards,
Mark.


Local ULAs might also be discovered through mDNS, which is I pretty much ubiquitous on home networks.

Op do 22 sep. 2022 om 01:25 schreef Brian E Carpenter <[e-mail]<mailto:[e-mail]>>
I agree with Bob that a stand-alone draft (Updates: 6724) is probably
a simpler approach than re-opening the whole RFC to comments.

Apart from that, the proto-draft says:

    An implementation MUST automatically add additional site-specific rows
    to the default table based on its configured addresses, such as for
    Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses,
    for instance (see Sections 10.6 and 10.7 for examples).

That doesn't really compute, because 6to4 is pretty much ancient history.
If we make a change of this kind, I think it should be specific to ULAs.
And if we want to make the section 10.6 behaviour mandatory, I think we'd
want the wording to be precise (with an explicit description of the
algorithm the kernel should use).

We should also, I think, state clearly that the expectation is that ULAs
will normally be discovered via split-horizon DNS, or some other local
discovery mechanism (e.g. the one in GRASP [RFC8990]).

The other question is: would it be sufficient to do something much simpler,
i.e., simply boost the ULA prefix in the default policy table and all
examples:

      fc00::/7              31    13

Where's the harm in that? It will mean that ULAs are picked by the
longest match rule when they are present. That won't happen unless
there *are* ULAs, so it has precisely zero impact on sites that don't
use them.

It does no harm to add higher precedence for locally defined ULAs, but
I am not convinced it's useful either, in the normal case.

The proto-draft also says:

    This behavior is required for proper functioning of ULA addressing,
    thus preserving the preference of IPv6 over legacy IPv4 in dual stacked
    environments as detailed in draft-v6ops-ula. Additionally, requiring
    local site-specific addressing entry into all nodes preference list
    further scopes the network communication to local and remote per the
    respective addressing blocks and creates a more consistent operational
    model and user experience.

I agree with the statement, but it would sit more naturally in a
stand-alone update than as a patch on RFC6724.

Regards
    Brian

On 21-Sep-22 20:47, Nick Buraglio wrote:
> I've gotten some feedback that the diff is hard to read because of the
> formatting, so here is a link to the proposal. Please bear in mind
> that this is *very* crude and was meant to simply track the idea.
> https://github.com/buraglio/ietf-draft-buraglio-rfc6724-update
>
> ----
> nb
>
> On Wed, Sep 21, 2022 at 10:29 AM Nick Buraglio <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> Totally agree - this is just a starting point. I am happy to work on
>> whatever the group feels is the right approach and what we feel will
>> reach consensus.
>>
>> ----
>> nb
>>
>> On Wed, Sep 21, 2022 at 10:25 AM Tim Chown <[e-mail]<mailto:[e-mail]>> wrote:
>>>
>>> Thanks Nick.
>>>
>>> I think the aim here is to see if the WG can get consensus on an approach to address the problem, and document that for consideration for WG adoption.  Nick has diffs below to 6724, but it could be a short standalone document the updates 6724.
>>>
>>> Tim
>>>
>>>> On 21 Sep 2022, at 09:02, Nick Buraglio <[e-mail]<mailto:[e-mail]>> wrote:
>>>>
>>>> The changes that I had proposed in my github repo are below, these are
>>>> just a starting point, I welcome any and all input.
>>>>
>>>>
>>>>
>>>> @@ -12,7 +12,7 @@ ISSN: 2070-1721
>>>>        A. Matsumoto
>>>>
>>>>
>>>>      Default Address Selection for Internet Protocol Version 6 (IPv6)
>>>> -
>>>> +                ietf-draft-buraglio-rfc6724-update.txt
>>>> Abstract
>>>>
>>>>     This document describes two algorithms, one for source address
>>>> @@ -347,14 +347,14 @@ RFC 6724           Default Address Selection for
>>>> IPv6     September 2012
>>>>        fec0::/10              1    11
>>>>        3ffe::/16              1    12
>>>>        fec0::/10              1    11
>>>>        3ffe::/16              1    12
>>>>
>>>> -   An implementation MAY automatically add additional site-specific rows
>>>> +   An implementation MUST automatically add additional site-specific rows
>>>>     to the default table based on its configured addresses, such as for
>>>>     Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses,
>>>>     for instance (see Sections 10.6 and 10.7 for examples).  Any such
>>>>     rows automatically added by the implementation as a result of address
>>>>     acquisition MUST NOT override a row for the same prefix configured
>>>>     via other means.  That is, rows can be added but never updated
>>>> -   automatically.  An implementation SHOULD provide a means (the
>>>> +   automatically.  An implementation MUST provide a means (the
>>>>     Automatic Row Additions flag) for an administrator to disable
>>>>     automatic row additions.
>>>>
>>>> @@ -363,7 +363,15 @@ RFC 6724           Default Address Selection for
>>>> IPv6     September 2012
>>>>     addresses, 6to4 source addresses with 6to4 destination addresses,
>>>>     etc.  Another effect of the default policy table is to prefer
>>>>     communication using IPv6 addresses to communication using IPv4
>>>> -   addresses, if matching source addresses are available.
>>>> +   addresses, if matching source addresses are available.
>>>> +
>>>> +   This behavior is required for proper functioning of ULA addressing,
>>>> +   thus preserving the preference of IPv6 over legacy IPv4 in dual stacked
>>>> +   environments as detailed in draft-v6ops-ula. Additionally, requiring
>>>> +   local site-specific addressing entry into all nodes preference list
>>>> +   further scopes the network communication to local and remote per the
>>>> +   respective addressing blocks and creates a more consistent operational
>>>> +   model and user experience.
>>>>
>>>>     Policy table entries for address prefixes that are not of global
>>>>     scope MAY be qualified with an optional zone index.  If so, a prefix
>>>> @@ -1541,7 +1549,7 @@ RFC 6724           Default Address Selection for
>>>> IPv6     September 2012
>>>>                     C., and M. Azinger, "IANA-Reserved IPv4 Prefix for
>>>>                     Shared Address Space", BCP 153, RFC 6598, April 2012.
>>>>
>>>> -
>>>> +
>>>>
>>>>
>>>>
>>>> @@ -1775,6 +1783,9 @@ Authors' Addresses
>>>>
>>>>
>>>> ----
>>>> nb
>>>>
>>>> On Tue, Sep 20, 2022 at 6:06 PM Tim Chown <[e-mail]<mailto:[e-mail]>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> As an author of RFC6724 I’ve had the discussions about a possible update of RFC6724 brought to my attention.
>>>>>
>>>>> An example thread over on v6ops is https://mailarchive.ietf.org/arch/msg/v6ops/W6HjHc11JX364soq3t3gFMHSawE/, but there are others.
>>>>>
>>>>> Nick Buraglio has documented the problem in draft-ietf-v6ops-ula-00.  The short of it is that RFC1918 IPv4 addresses may be preferred to IPv6 ULAs in certain circumstances, which I would agree is not desired behaviour.
>>>>>
>>>>> There are a few ways we might look to address this.  There is a proposal from Nick (not yet published outside a git repo) to address it by changing wording in section 2.1, with a couple of MAYs becoming MUSTs, and adding an extra explaining paragraph.  This basically firms up the requirement to follow 6.10 on adding an extra precedence line for local ULA prefix(es).
>>>>>
>>>>> Now, that may or may not be the preferred solution of the WG, but I think there’s a few questions to consider:
>>>>>
>>>>> 1. Is there agreement we should address the problem?  I’d assume so because Nick's problem draft was adopted by v6ops.
>>>>>
>>>>> 2. If so, is 6man the place to do it?  I think it has to be.  RFC6724 was born here.
>>>>>
>>>>> 3. How do we determine the best solution to the problem?  I suspect there are nuances in play that will make a one size fit all ’simple’ fix tricky, but I look forward to the discussion.  Nick has one proposal that counts to a couple of word changes and an extra paragraph, which I’d encourage him to share here, but there are other approaches proposed on v6ops.  I think either way, it will require some update to or for RFC6724.
>>>>>
>>>>> 4. Does this work warrant a full -bis or would a separate RFC that updates 6724 be better?  A separate Updating draft might better highlight the issue to implementors.  But then RFC6724 is now ten years old, and RFC3484 which it replaced was nine years before that.
>>>>>
>>>>> 5. If we choose to open up a full -bis, are there any other worms in this can?  I have a feeling also here I know the likely answer….
>>>>>
>>>>> Anyway, over to the WG… thoughts?
>>>>>
>>>>> Tim
>>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]<mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--
===============================================
David Farmer               Email:[e-mail]<mailto:[e-mail]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================