Re: [v6ops] Thoughts about wider operational input

[Ted Lemon <[e-mail]>]

Okay, but what does that have to do with ULAs and NAT64?

On Tue, Mar 22, 2022 at 10:05 PM Nick Buraglio <[e-mail]> 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>
> > >
> >
>