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

[Ted Lemon <[e-mail]>]

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.

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.

On Fri, Apr 5, 2024 at 2:45 AM David Farmer <farmer=[e-mail]>
wrote:

>
> On Thu, Apr 4, 2024 at 2:52 PM Brian E Carpenter <
> [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] 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/
>> >
>> > There is also an HTMLized version available at:
>> > 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
>> >
>> > Internet-Drafts are also available by rsync at:
>> > rsync.ietf.org::internet-drafts
>> >
>> >
>> > _______________________________________________
>> > I-D-Announce mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/i-d-announce
>> >
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>
> --
> ===============================================
> David Farmer               Email:[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]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>