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

[David Farmer <[e-mail]>]

On Fri, Apr 5, 2024 at 9:30 AM Ted Lemon <[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?

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]> 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
>> --------------------------------------------------------------------
>>
>

-- 
===============================================
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
===============================================