Re: [v6ops] Thoughts about wider operational input

[Ted Lemon <[e-mail]>]

In principle, what Android doesn't implement is IA_NA, not DHCP Information
Request. So in principle, this could be a solution for Android at some
point.

On Thu, Mar 24, 2022 at 3:02 AM Brian E Carpenter <
[e-mail]> wrote:

> On 24-Mar-22 13:22, Mark Andrews wrote:
> > RFC 6724, Default Address Selection for Internet Protocol Version 6
> (IPv6)
> >
> >     An implementation MAY 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
> >     Automatic Row Additions flag) for an administrator to disable
> >     automatic row additions.
> >
> > RFC 7078 Distributing Address Selection Policy Using DHCPv6 instead of
> > using puppet.
>
> i.e., not for Android...
>
>     Brian
>
> >
> >> On 24 Mar 2022, at 08:41, Nick Buraglio <[e-mail]> wrote:
> >>
> >> This is very interesting, and it definitely was something I was not
> aware of. I am guessing this is also fairly unknown to others as well.
> >> Is there any more documentation on the intention of this table as it
> pertains to multiple platforms and embedded systems? I’d love to read
> whatever is available, and I’ll do a bit more research myself
> to see what is out there.
> >>
> >> nb
> >>
> >> On Wed, Mar 23, 2022 at 15:48 Mark Andrews <[e-mail]> wrote:
> >> The table is designed to be patched for local topology. You add in the
> local ULA prefixes before IPv4.  The default will allow connection to
> succeed provided hosts and links are up and configured as expected on the
> first attempt.   If you push ULA above IPv4 and you have a non reachable
> ULA you are need fast failover to the next address.
> >>
> >> The OP complaint about the table indicates lack of understanding of
> what is intended.
> >>
> >> Note there are defined mechanisms for distributing a more site specific
> table. The OS and administrators should avail themselves of them.  A node
> doesn’t necessarily have the requisite knowledge to do this for itself
> (multiple ULA prefixes reachable). It can add directly connected
> prefixes.
> >> --
> >> Mark Andrews
> >>
> >>> On 24 Mar 2022, at 07:07, Brian E Carpenter <
> [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]> 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]] On Behalf Of Brian E
> Carpenter
> >>>>> Sent: Tuesday, March 22, 2022 11:48 PM
> >>>>> To: [e-mail]; Ted Lemon <[e-mail]>
> >>>>> Cc: [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]>> 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
> >>>
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >> --
> >> ---
> >> Nick Buraglio
> >> Planning and Architecture
> >> Energy Sciences Network
> >> [phone]
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>