Re: [v6ops] Thoughts about wider operational input

[Daniel Woititz <[e-mail]>]

Hi Nick,

Is it the right place to do so?
I think so. The technology needs to be useful. Even though the IETF is non-profit, the users should be thought of as customers. Learn customer needs and then work from there. maybe we should used the word "consumer" instead of "customer".

How can the IETF provide guidance that fills that gap?
This, and probably many other items, would go back to the answer above. Who and how are the major consumers of the product. How to best cater to them?

On 3/23/22 9:52 PM, Nick Buraglio wrote:
> The point I am trying to make is to address the initial question about
> enterprise deployment of IPv6. The fact that we are talking about
> manually changing the behavior of an off the shelf operating system,
> and that the behavior may be inconsistent at best and incorrect at
> worst across said systems /is/ the impediment. As Chongfeng states
> further up the thread, there is a sizable gap between IETF and
> enterprise deployment, where "enterprise" is defined as somewhere that
> the network is a cost center that enables their business.
> My counter-questions are these:
> How can the IETF provide guidance that fills that gap?
> Is it the right place to do so?
>
> nb
>
> On Tue, Mar 22, 2022 at 5:41 PM Brian E Carpenter
> <[e-mail]>  wrote:
>> Nick,
>>
>> I'm familiar with RFC6724. It says this:
>>
>> "  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."
>>
>> That seems to be incorrect. To make it true, the entry should be
>>
>>    fc00::/7              39    13
>>
>> if I have that right. That would still give precedence to GUAs
>> if available. 41 would give precedence to ULAs.
>>
>> Regards
>>      Brian Carpenter
>>
>> On 23-Mar-22 10:04, Nick Buraglio wrote:
>>> In RFC6724 section 2.1 states:
>>>
>>> If an implementation is not configurable or has not been configured,
>>> then it SHOULD operate according to the algorithms specified here in
>>> conjunction with the following default policy table:
>>>
>>>         Prefix        Precedence Label
>>>         ::1/128               50     0
>>>         ::/0                  40     1
>>>         ::ffff:0:0/96         35     4
>>>         2002::/16             30     2
>>>         2001::/32              5     5
>>>         fc00::/7               3    13
>>>         ::/96                  1     3
>>>         fec0::/10              1    11
>>>         3ffe::/16              1    12
>>>
>>> https://datatracker.ietf.org/doc/html/rfc6724#section-2.1
>>>
>>> Linux is /theoretically/ configurable but implementations are
>>> inconsistent. Even so, changing this at scale is operationally
>>> impossible and would present as a huge impediment for any deployment
>>> of size. My experience has been that most implementations have taken
>>> the "...implementation is not configurable" approach, and that has
>>> become the de facto standard. Again, if we are talking about
>>> impediments to enterprise deployment, this is on the list. It is
>>> unrealistic to expect or require a sweeping change to a protocol
>>> default by a random enterprise deployment team. We went quite deep in
>>> this thread back in August of 2021 on this list. I am also happy to be
>>> wrong here.
>>>
>>> nb
>>>
>>> ---
>>> Nick Buraglio
>>> Planning and Architecture
>>> Energy Sciences Network
>>> [phone]
>>>
>>>
>>> On Tue, Mar 22, 2022 at 3:48 PM Brian E Carpenter
>>> <[e-mail]>  wrote:
>>>> 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-networks/  <https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-networks/>
>>>>>
>>>>> nb
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Mar 22, 2022 at 3:20 PM Ted Lemon <[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]>> 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]>> 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]>
>>>>>               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  <https://www.ietf.org/mailman/listinfo/v6ops>
>>>>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
-- 

Thank you,

Danny Woititz
Founder and Primary Author of MasterIPv6.com <https://www.MasterIPv6.com>