Re: [v6ops] Thoughts about wider operational input

[Vasilenko Eduard <[e-mail]>]

Ø  we would have to add additional rules that explicitly test for this situation.
+1

From: Ted Lemon [mailto:[e-mail]]
Sent: Thursday, March 24, 2022 12:42 PM
To: Brian E Carpenter <[e-mail]>
Cc: [e-mail]; Vasilenko Eduard <[e-mail]>; [e-mail]
Subject: Re: [v6ops] Thoughts about wider operational input

Of course, the situation is a bit more complicated than you've said, because we do both source and destination address selection, and the decision of whether to use IPv4 is actually impacted by both choices. I think what we really want is that if the destination address is an IPv4 address, obviously we choose IPv4, but if we have both an IPv4 and IPv6 destination addresses, then we may be able to choose IPv6, but not necessarily.

If all we have for IPv6 is a ULA, and the destination address is a GUA, there's no guarantee that communication is possible in both directions using the ULA, so we might have to prefer to use IPv4 in this case. If the destination address is a ULA with the same global ID, then I think it's safe to prefer the ULA source address. If it's a ULA with a different global ID, I don't think this is a safe assumption; in this case it's probably safer to use IPv4.

So I don't agree with you Brian that the table is wrong—I suspect it was written this way because it was the only way to write the table that ensured that the right thing would happen in this corner case. In order to address this corner case while preferring a ULA over an IPv4 source address, we would have to add additional rules that explicitly test for this situation.

On Wed, Mar 23, 2022 at 9:07 PM Brian E Carpenter <[e-mail]<mailto:[e-mail]>> wrote:
Eduard, you wrote:

> I am puzzled why ::ffff:0:0/96 has been treated as IPv4? Strange interpretation.

Not at all strange. By definition (see RFC4291, section 2.5.5.2) that is the entire
IPv4 address space, respresented as an IPv6 prefix.

The problem is that RFC 6724 asserts that it sets IPv6 precedence above IPv4,
but in fact it sets ULA precedence below IPv4. That is a glaring error in
RFC 6724 - either text is wrong or the table is wrong. The behaviour that
Nick
reports is conformance to the default table in RFC 6724, which is non-confromance
to the text.

Regards
    Brian Carpenter

On 24-Mar-22 02:53, Nick Buraglio wrote:
> My testing and experience has shown this, yes, and I know others have
> had this experience as well.
>
> nb
>
>
>
> On Wed, Mar 23, 2022 at 3:37 AM Vasilenko Eduard
> <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> Nick has given a URL with a detailed explanation. It has:
>> "ULA per RFC 6724 is less preferred (the Precedence value is lower) than all IPv4 (represented by ::ffff:0:0/96 in the table)."
>> I am puzzled why ::ffff:0:0/96 has been treated as IPv4? Strange interpretation.
>> The same section 2.1 has: "
>> 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.
>> "
>> Nothing is stated about IPv6 type, "any" is assumed (including ULA).
>>
>> Nick, are you sure that IPv4 prioritization over IPv6 ULS is really the case for real OSes?
>> If yes, IMHO: it is the bug in implementation (non-compliance to RFC 6724).
>>
>> /Ed
>> -----Original Message-----
>> From: v6ops [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Brian E Carpenter
>> Sent: Tuesday, March 22, 2022 11:48 PM
>> To: [e-mail]<mailto:[e-mail]>; Ted Lemon <[e-mail]<mailto:[e-mail]>>
>> Cc: [e-mail]<mailto:[e-mail]>
>> Subject: Re: [v6ops] Thoughts about wider operational input
>>
>> Nick,
>>
>> Where is the "prefer IPv4 over ULA" preference coded (whereas, presumably, "prefer IPv4 over GUA" is not coded)?
>>
>> Regards
>>      Brian Carpenter
>>
>> On 23-Mar-22 09:35, Nick Buraglio wrote:
>>> Yes, I know I have harped on this many times and have posted some
>>> simple examples of the behavior to the list. My experience has been,
>>> and continues to be, that if I have dual stacked hosts with A and AAAA
>>> records, and the IPv6 clients are using ULA that IPv6 is never used.
>>> In an IPv6-only environment ULA has no higher priority protocol to
>>> supersede the ULA. In the context of transitioning to an IPv6 world,
>>> it is fairly unrealistic to assume any kind of greenfield, and
>>> dual-stack
>> is by and large the standard "permanently temporary" solution for the vast majority of implementations. So in this context, which has been 99% of what I have seen until I began working on the IPv6-only implementation
mandated by the USG OMB-M-21-07 document, that was the de facto standard (and will continue to be for enterprise deployments, in my opinion).
>>> I would be happy to be incorrect about this, honestly it would make my
>>> work-life easier if I was. So, yes, I fully acknowledge that your use
>>> case is absolutely the right one for ULA. For doing a transition in an
>>> existing network (which circles back the the original topic of this
>>> thread: getting enterprises to use IPv6 in a meaningful way), this is
>>> a really
>> well put together descriptions of the every-day implications of trying
to use ULA:
>>> https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-networ
>>> ks/
>>> <https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-netwo
>>> rks/>
>>>
>>> nb
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Mar 22, 2022 at 3:20 PM Ted Lemon <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>
>>>      I'm sure you believe this assertion, Nick, but you haven't given
>>> us
>> any way of understanding why you believe this. In fact we're using ULAs in the Thread Border Router to enable IPv6 communication between different subnets, which literally could not be done with IPv4. So at least for
this use case, ULAs work well. Would it work better to have a GUA? Comme ci comme ça. On the one hand, prefix delegation and real routing would make the solution more general. On the other, GUAs are great for reaching out to the internet, which we may or may not want light bulbs to be able to do.
>>>
>>>      On Tue, Mar 22, 2022 at 9:13 PM Nick Buraglio <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>
>>>          ULA is an operational non-starter in the presence of any dual stacked hosts.  Per its design, it just won't ever use IPv6 in any meaningful way and that time and effort are better served on adding GUA addressing of one kind or another.
>>>
>>>          nb
>>>
>>>
>>>
>>>          On Tue, Mar 22, 2022 at 2:55 PM Brian E Carpenter <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>
>>>              Hi Gert,
>>>
>>>              I see that the discussion has been going on while I was sleeping, but I want to clarify below...
>>>              On 22-Mar-22 21:30, Gert Doering wrote:
>>>               > Hi,
>>>               >
>>>               > On Tue, Mar 22, 2022 at 11:42:12AM +1300, Brian E Carpenter wrote:
>>>               >> I agree with Jordi that multihoming is a genuine impediment. What isn't generally realised is that it's a problem of scale when considering at least 10,000,000 enterprises, much more than it's a problem of IPv6 itself.
>>>               >
>>>               > What is "an enterprise"?
>>>               >
>>>               > My stance on this is that for "largely unmanaged SoHo
networks" - which
>>>               > could be called "small enterprise" - dual-enduser-ISP
with dual-/48 or
>>>               > NPT66 gets the job done in an easy and scalable way (HNCP would have
>>>               > been great, but IETF politics killed it).
>>>               >
>>>               > "Enterprise that truly need their own independent fully managed network
>>>               > with multiple ISP uplinks and fully routed independent address space"
>>>               > are probably way less than 10 million...
>>>
>>>              I came up with 10 million quite some years ago as a reasonable estimate
>>>              of the number of medium to large businesses in the world, all of which
>>>              might depend on *reliable* Internet access to survive (and WfH during
>>>              COVID has made this even more important recently). So all of them
>>>              should have two independent paths to the Internet to
>>> assure
>> reliability.
>>>              That means two different ISPs (or less good, two
>>> completely
>> independent
>>>              paths to the same ISP).
>>>
>>>              So, if PI addressing is the answer, that really does take us to
>>>              10M /48s to be routed.
>>>
>>>              If PA is the answer, that's why I worked on SHIM6 (may it rest in
>>>              peace). Which is why I worked on RFC 8028. If that's not
the
>>>              answer, we're back to NPTv6. Possibly even to ULA+NPTv6.
>>>
>>>               > Half of them do not want Internet access anyway, just
access to their
>>>               > ALGs that will do the filtering and TLS inspection and everything, and
>>>               > then out to the Internet as a new TCP session (= could
>> be done with
>>>               > DMZ islands of upstream-provider-allocated space just
fine).
>>>               >
>>>               >
>>>               > We need to work on our marketing regarding multihoming.  "What is it that
>>>               > you get, what is the cost, which of the variants do you want, and why...?"
>>>
>>>              Yes.
>>>                   Brian
>>>
>>>              _______________________________________________
>>>              v6ops mailing list
>>>              [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>              https://www.ietf.org/mailman/listinfo/v6ops
>>> <https://www.ietf.org/mailman/listinfo/v6ops>
>>>
>>>          _______________________________________________
>>>          v6ops mailing list
>>>          [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>          https://www.ietf.org/mailman/listinfo/v6ops
>>> <https://www.ietf.org/mailman/listinfo/v6ops>
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/v6ops