Re: [IPv6] ULA vs. 1918

["Pascal Thubert (pthubert)" <[e-mail]>]

I can imagine the complexity. We live through it every time 2 companies with an RFC 1918 private network in the same range merge. And it happens all the time. This is actually one of the arguments for going v6. Now, that argument would only work for GUAs.
With NEMO we had that use case called nested NEMO where cars own prefixes and attach to one another in a daisy chain or a MANET to reach the internet. a car would build a CoA from another car's network.
The there's a home gateway with its RFC 1918 prefix out of the box. I guess we'd like to translate that into ULAs. What if I have 2 of them? Seems to me that SLAC is probably taking us to scenarios where there are more than 1 ULA prefix at home.
Bottom line is that I cannot see that we can avoid having more than one ULA prefix in a site, and interconnecting sites with different ULA prefixes.
If we cannot take the complexity, there's probably no point wasting time on ULAs.

regards,

Pascal
________________________________
De : ipv6 <[e-mail]> de la part de Brian E Carpenter <[e-mail]>
Envoyé : samedi 17 juin 2023 00:15
À : Mark Andrews <[e-mail]>; Ted Lemon <[e-mail]>
Cc : 6man list <[e-mail]>; [e-mail] <[e-mail]>
Objet : Re: [IPv6] ULA vs. 1918

On 16-Jun-23 17:17, Mark Andrews wrote:
> I don’t think what I wrote is in disagreement with Kyle.  Kyle has a simplified scenario.  Every ULA is in the same site.  This is not always the case.  In fact every CPE router lives in two (or more) sites regardless of whether ULA are in use or not.  Bastion hosts often live in multiple sites.
>
> I’d actually like to publish ULAs tied to a globally unique site identifier in the DNS and have getaddrinfo optionally filter out non local ULAs.  Yes it would require moving to something other that AAAA records.

That would be a gross misuse of ULAs and would create unimaginable operational complexities. ULAs don't cross site boundaries, and every CE router is supposed to enforce that (RFC 7084, recommendation ULA-4).

ULAs are site-local, end of story.

    Brian

>
>> On 16 Jun 2023, at 09:47, Ted Lemon <[e-mail]> wrote:
>>
>> Mark, I think you should reread what Kyle wrote. I agree with it 100%. The reason to black hole fc00::/7 is to avoid losing when there is a misconfiguration. It is unnecessary when things are configured correctly. I think Kyle’s analysis of the failure modes was spot on.
>>
>> Op do 15 jun 2023 om 19:42 schreef Mark Andrews <[e-mail]>
>>
>>
>>> On 15 Jun 2023, at 12:41, Brian E Carpenter <[e-mail]> wrote:
>>>
>>> On 15-Jun-23 13:36, Mark Andrews wrote:
>>>> Local to where?  ULAs leak.  They are published in the global DNS.  They end up in other places like /etc/hosts. They end up being used on sites they are not local too.
>>>
>>> Where they cannot possibly work. So it really doesn't matter if such misconfigurations don't work with whatever we do under the banner of RFC6724bis - they are irretrievably broken and not worth discussing in 6man.
>>>
>>>     Brian
>>
>> We have most of ::/0 reachable.  We have most of fc00::/7 that is unreachable (actively null routed).  We have some local parts of fc00::/7 that we know are reachable.
>>
>> We have every node being multi-homed in multiple ways.  IPv4 (maybe partitioned), LL (multiple scopes), ULA (multiple sites), GUA (maybe partitioned).
>>
>> Now we can have every node run a routing protocol so that we know which parts of fc00::/7 are reachable via which interfaces or we can distribute tables or we can build up approximate tables from the interfaces.  We need tables even if we have no leaks of addresses as longest match will produce the WRONG match on nodes connected to multiple sites of you treat ULA as a single entity.  We also need rules for how to combine tables learnt from different interfaces.
>>
>>>>> On 15 Jun 2023, at 11:05, Fred Baker <[e-mail]> wrote:
>>>>>
>>>>> Under what circumstances would a Unique Local Address not be local?
>>>>>
>>>>> Sent using a machine that autocorrects in interesting ways...
>>>>>
>>>>>> On Jun 14, 2023, at 6:02 PM, Kyle Rose <[e-mail]> wrote:
>>>>>>
>>>>>> Thanks, but boy, am I sorry I kicked the hornet's nest. ;-)  I was not aiming to reignite what appears to be a long-running debate, but maybe it's unavoidable.
>>>>>>
>>>>>> I'm thinking an explanation of my particular (I think pretty natural?) use case would provide context for what I'm looking to solve.
>>>>>>
>>>>>> Here are my priors:
>>>>>>
>>>>>> (1) Machines on my LAN are assigned 1918 addresses either statically or by DHCP, but IPv4 may be broken on any particular client for unstated reasons.
>>>>>>
>>>>>> (2) Machines on my LAN self-assign IPv6 addresses using SLAAC, both with my network's ULA prefix and with my provider's (cascaded) PD assignment. (But I think this could be replaced by static assignment or via DHCPv6 without changing any of the analysis, as long as the addresses are assigned with the same prefixes.) As with IPv4, IPv6 could be broken for unstated reasons: a client could lack either a ULA or a GUA or both.
>>>>>>
>>>>>> (3) I run my own internal DNS that resolves internal service names only to other internal nodes: all others get denied.
>>>>>>
>>>>>> (4) If I see a ULA in a DNS response, that is either some reachable node, or is a misconfiguration. (I.e., I should not encounter a ULA that is unreachable via my internal network routing topology, and if I do, I screwed up.)
>>>>>>
>>>>>> Here are my goals:
>>>>>>
>>>>>> (a) Resolve internal service names to both IPv4 and IPv6 addresses, and do so statically (without the use of ddns).
>>>>>>
>>>>>> (b) Internal connections should not fail because of a change in provider PD.
>>>>>>
>>>>>> (c) Always connect successfully when either IPv4 or IPv6 (or both) is working.
>>>>>>
>>>>>> (d) Nice-to-have: Prefer IPv6 when available.
>>>>>>
>>>>>> If internal service names have A records to 1918 addresses and AAAA records to ULAs, goals (a) and (b) are satisfied. However, goals (c) and (d) are not satisfied so long as ULA has a different label than GUA and lower precedence than IPv4:
>>>>>>
>>>>>> * IPv4 will be preferred internally because of the GUA/ULA label mismatch and the lower precedence of ULA compared to IPv4. This violates goal (d).
>>>>>>
>>>>>> * Happy eyeballs will consider only IPv4 destinations for the same reason, so if IPv4 is broken in some unknown way, the client will never even try IPv6. This violates goal (c).
>>>>>>
>>>>>> My contention is that removing the lower precedence while keeping the distinct label for ULA resolves this issue by putting ULA and IPv4 back on the same footing for internal connections.
>>>>>>
>>>>>> Among the side-effect implications of this change are:
>>>>>>
>>>>>> * Under normal circumstances a client will never try to connect GUA->ULA or ULA->GUA, as v4 would be preferred via the ULA/GUA label mismatch. The former would be benign, but the latter would run into the lack of NAT66 at the network boundary, which I don't implement and I get the feeling is not very common. If both GUA and IPv4 are broken, a client would try and probably fail; but at that point you're in best effort territory anyway.
>>>>>>
>>>>>> * ULA->ULA will always be preferred over other possibilities, which means services exposing both a ULA and a GUA via DNS (or some other means of rendezvous) had better be reachable via ULA. If they aren't, go back to prior (4): this is a misconfiguration. Don't expose addresses clients can't reach under the assumption that address selection will somehow prevent connection failures (!!)
>>>>>>
>>>>>> Does this make sense?
>>>>>>
>>>>>> Thanks,
>>>>>> Kyle
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 14, 2023 at 11:12 AM Nick Buraglio <[e-mail]> wrote:
>>>>>> FWIW with the collaboration of one of the original authors, there is a completed update draft for 6724 that will be submitted for input to 6man that addresses some of these issues very, very soon.
>>>>>>
>>>>>> nb
>>>>>>
>>>>>> On Wed, Jun 14, 2023 at 1:28 PM Vasilenko Eduard <[e-mail]> wrote:
>>>>>> The fixed table may work:
>>>>>> “Rule 5: Prefer matching label” would not permit to use ULA to connect GUA
>>>>>> And
>>>>>> “Rule 6: Prefer higher precedence” could prioritize ULA below GUA but above IPv4
>>>>>>   It would cover the situation with many /48 in one organization.
>>>>>>   If destination has only ULA DNS record (for internal host) – then connection would happen over ULA.
>>>>>> Ed/
>>>>>> From: ipv6 [mailto:[e-mail]] On Behalf Of Mark Andrews
>>>>>> Sent: Wednesday, June 14, 2023 5:45 AM
>>>>>> To: Lorenzo Colitti <lorenzo=[e-mail]>
>>>>>> Cc: [e-mail]; [e-mail]
>>>>>> Subject: Re: [IPv6] ULA vs. 1918
>>>>>>   We need to stop thinking about ULA as a single thing but rather ULA  scoped addressed /10 and directly connected (reachable) ULA prefixes /48s.
>>>>>>    A FIXED table does not work if the node has ULA addresses. The stack needs to add entries based on the contents of the RAs the node sees.
>>>>>>    The light bulb needs a little bit of smarts.
>>>>>> --
>>>>>> Mark Andrews
>>>>>>
>>>>>>
>>>>>> On 14 Jun 2023, at 12:02, Lorenzo Colitti <lorenzo=[e-mail]> wrote:
>>>>>>  I think the problem is that if we just remove ULA from the table, then ULA-to-GUA (or GUA-to-ULA) will be preferred over IPv4-to-IPv4, which is not what we want because IPv4 addresses have global reachability but ULAs do not. So ULA needs to remain in the table because it needs its own label.
>>>>>>    On Wed, Jun 14, 2023 at 6:16 AM Kyle Rose <[e-mail]> wrote:
>>>>>> Thanks, Ed. I've added the draft authors pseudo-address to this reply.
>>>>>>    I read the draft. I *believe* one bit of confusion I initially ran into is cleared up by the destination address selection rules in RFC 6724 section 6, but I'd like some confirmation. If the local dual-stack machine has a 1918 address (NATed by the site's firewall) and only a ULA for v6 (*not* NATed), and attempts to connect to a dual-stack server on the public internet, destination address selection would prefer the server's v4 address because label(dest_v4)=label(src_v4) while label(dest_v6) != label(src_v6) under the rules that assign GUA and ULA addresses different labels.
>>>>>>    Is that right?
>>>>>>    If so, I think the implication here bears stating in the document: that simply removing the reduced precedence for ULA addresses specified in section 2.1 of 6724 would typically result in dual stack clients connecting to dual stack servers via:
>>>>>>     * v6 when the client has GUA and the server is available via GUA, or when the client has ULA and the server is available via ULA
>>>>>>   * v4 otherwise
>>>>>>    which AFAICT is the behavior I want for my site with GUA via DHCPv6 PD:
>>>>>>     * Use GUA when server offers GUA and the client has GUA
>>>>>>   * Use ULA when server offers ULA but not GUA (e.g., service is internal and DNS is static and therefore has only ULA and 1918 records) or when server offers both ULA and GUA but client lacks GUA
>>>>>>   * Use v4 when server offers GUA but not ULA and client lacks GUA (i.e., assume ULA will be blackholed at the firewall)
>>>>>>    I'll note that I already observe this behavior in my Debian bookworm installations, which suggests the defaults specified in comments in /etc/gai.conf (which matches the gai.conf quoted in the draft) accurately represent the default behavior of Debian's getaddrinfo build.
>>>>>>    Kyle
>>>>>>      On Tue, Jun 13, 2023 at 3:02 PM Ed Horley <[e-mail]> wrote:
>>>>>> Kyle,
>>>>>> Nick and Russ did some work around this in a draft, please see: https://datatracker.ietf.org/doc/draft-buraglio-v6ops-ula-use-cases/
>>>>>> The goal was to define the problem so that a reasonable approach to addressing the issue could be done because everyone has a common understanding of the issue.
>>>>>> I know that Brian was also working with Nick around seeing if it makes sense to update RFC 6724 (In my opinion it likely does) but it still does not solve the problem for the short to medium term (5 years or less - is that medium term?)
>>>>>> Regards,
>>>>>> Ed
>>>>>>    On Tue, Jun 13, 2023 at 10:43 AM Kyle Rose <[e-mail]> wrote:
>>>>>> After recently learning that default address selection recommended by RFC 6724 prefers (v4) 1918 addresses to (v6) ULA addresses, I did a brief list archive search and found what I think is the most recent discussion of this on the list, from September of last year:
>>>>>>    https://mailarchive.ietf.org/arch/msg/ipv6/tGYV3jeKDOKH-BcQu7uRXIJcaY8/
>>>>>>    It doesn't seem to have been resolved one way or the other, unless some discussions happened off-list that weren't later captured there. Does 6man have an official position on whether or not to rev default address selection? I know there is significant interest in at least preferring ULA to 1918, i.e., vs. treating ULA as equivalent to GUA and therefore preferring ULA to all of IPv4; but I don't want to reopen something that has been definitively rejected by the WG for good reasons.
>>>>>>    Thanks,
>>>>>> Kyle
>>>>>>    --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> [e-mail]
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>>>
>>>>>>    --
>>>>>> Ed Horley
>>>>>> [e-mail] | [phone]
>>>>>> Advancing Cloud, IoT, and Security with IPv6
>>>>>> https://hexabuild.io
>>>>>> And check out the IPv6 Buzz Podcast at https://packetpushers.net/series/ipv6-buzz/
>>>>>> --------------------------------------------------------------------
>>>>>>
>>>>>> IETF IPv6 working group mailing list
>>>>>> [e-mail]
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> [e-mail]
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> [e-mail]
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> [e-mail]
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: [phone]              INTERNET: [e-mail]
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------