Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-07.txt

[Brian E Carpenter <[e-mail]>]

On 06-Apr-24 07:15, David Farmer wrote:
> 
> 
> On Fri, Apr 5, 2024 at 9:30 AM Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     It's not at all clear to me that the burden of implementation here is sufficient to justify constrained devices not implementing the policy table update. If we want to do that, I think we need to explain exactly what sort of device we are talking about. Does the device not listen to RAs? Does it always send packets to the default router? If not, it's probably already doing things equivalently hard to maintaining a policy table.
> 
> 
> I think we are good as long as the constrained device meets the host type C specification in RFC4191.
> 
>     Furthermore, what I originally proposed to address this was to simply change the policy table without requiring it to be dynamically updated: rather than having one type of ULA, have two: known and unknown ULAs. Known ULAs have a higher priority than IPv6 GUAs and IPv4 addresses. Unknown ULAs continue to be treated as before.
> 
>     What then needs to be maintained is a list of known ULAs. I realize that this isn't /that/ different from updating the policy table, but it is a bit simpler in the sense that there's no complexity to it—you're just keeping track of a list of ULAs, and when you do source/dest address selection each ULA is checked against that table before checking against the policy table.
> 
>     If constrained devices already support the policy table, I do not think this additional work is onerous.
> 
> 
> How would the "known-local" ULA prefixes be populated if not dynamically updated from PIOs and RIOs?

By the simple fact that a host actually has a ULA. This is the approach I used in three different userland hacks:

https://github.com/becarpenter/misc/blob/main/enable_ula.py
https://github.com/becarpenter/misc/blob/main/gai_wrap.py
https://github.com/becarpenter/getapr/

    Brian

> 
> My worry wasn't about constrained devices not supporting the policy table; my worry is whether there are any constrained devices of Type A or B from RFC4191 that don't support RIOs.
> 
>     On Fri, Apr 5, 2024 at 2:45 AM David Farmer <farmer=[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>         On Thu, Apr 4, 2024 at 2:52 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>             All good changes, thanks.
> 
> 
>         +1
> 
>             About this in section 3:
> 
>             "AUTHORS' NOTE: The authors have had feedback suggesting this requirement should be a MUST, which would mean that "known-local" ULAs would take precedence on compliant implementations over all IPv6 GUAs and all IPv4 addresses, but other general ULAs would not."
> 
>             I think the answer is clear, in section 8:
> 
>             "Receiving a DNS response for a ULA destination that is not attached to the local network... will typically fail..."
> 
>             That justifies the MUST in my opinion. But I agree we need to hear from kernel implementers.
> 
> 
>         Ideally, I'd like to see all IPv6 implementations automatically insert "known-local" ULAs into their policy table. From that point of view, I support MUST.
> 
>         However, should constrained devices be an exception? If so, are there any other exceptions? If there are exceptions, SHOULD might make more sense than MUST.
> 
>         Also, SHOULD allows for a two-phase implementation approach. Phase one is a mostly trivial change to the default policy table that can be implemented quickly and easily. Phase two is a fairly complicated addition of a new feature for inserting "known-local" ULAs into the policy table that probably needs quite a bit of testing before going into production.
> 
>         In the long run, MUST is the right answer. However, SHOULD could have some short-term advantages.
> 
>         In either case, since I'm not aware of any implementations of the current MAY, I'd like to see some proof-of-concept running code to make sure what we think we are saying is actually doable.
>         Thanks.
> 
>             Nit: in the .txt version, there is a glitch in the rendering of Rule 5
>             at the beginning of section 8.1 - the newlines have been lost.
> 
> 
>         There are a number of rendering glitches that I mentioned previously.
> 
>             Regards
>                  Brian Carpenter
> 
>             On 05-Apr-24 08:05, [e-mail] <mailto:[e-mail]> wrote:
>              > Internet-Draft draft-ietf-6man-rfc6724-update-07.txt is now available. It is a
>              > work item of the IPv6 Maintenance (6MAN) WG of the IETF.
>              >
>              >     Title:   Preference for IPv6 ULAs over IPv4 addresses in RFC6724
>              >     Authors: Nick Buraglio
>              >              Tim Chown
>              >              Jeremy Duncan
>              >     Name:    draft-ietf-6man-rfc6724-update-07.txt
>              >     Pages:   15
>              >     Dates:   2024-04-04
>              >
>              > Abstract:
>              >
>              >     When RFC 6724 was published it defined an address selection algorithm
>              >     along with a default policy table, and noted a number of examples
>              >     where that policy table might benefit from adjustment for specific
>              >     scenarios.  It also noted that it is important for implementations to
>              >     provide a way to change the default policies as more experience is
>              >     gained.  This update draws on several years of operational experience
>              >     to refine RFC 6724 further, with particular emphasis on preference
>              >     for the use of ULA addresses over IPv4 addresses and the addition of
>              >     mandatory support for Rule 5.5.  The update also demotes the
>              >     preference for 6to4 addresses.  The changes to default behavior
>              >     improve supportability of common use cases, including automatic /
>              >     unmanaged scenarios.  It is recognized that some less common
>              >     deployment scenarios may require explicit configuration or custom
>              >     changes to achieve desired operational parameters.
>              >
>              > The IETF datatracker status page for this Internet-Draft is:
>              > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-update/ <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-update/>
>              >
>              > There is also an HTMLized version available at:
>              > https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6724-update-07 <https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6724-update-07>
>              >
>              > A diff from the previous version is available at:
>              > https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-rfc6724-update-07 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-rfc6724-update-07>
>              >
>              > Internet-Drafts are also available by rsync at:
>              > rsync.ietf.org::internet-drafts
>              >
>              >
>              > _______________________________________________
>              > I-D-Announce mailing list
>              > [e-mail] <mailto:[e-mail]>
>              > https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
>              >
> 
>             --------------------------------------------------------------------
>             IETF IPv6 working group mailing list
>             [e-mail] <mailto:[e-mail]>
>             Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>             --------------------------------------------------------------------
> 
> 
> 
>         -- 
>         ===============================================
>         David Farmer Email:[e-mail] <mailto:[e-mail]>
>         Networking & Telecommunication Services
>         Office of Information Technology
>         University of Minnesota
>         2218 University Ave SE        Phone: [phone]
>         Minneapolis, MN 55414-3029   Cell: 612-812-9952
>         ===============================================
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list
>         [e-mail] <mailto:[e-mail]>
>         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>         --------------------------------------------------------------------
> 
> 
> 
> -- 
> ===============================================
> David Farmer Email:[e-mail] <mailto:[e-mail]>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================