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

I think the behavior would be correct in this case: if the device doesn't
support RIO, then it probably shouldn't treat ULAs that appear in RIOs as
known-local.

On Fri, Apr 5, 2024 at 2:16 PM David Farmer <farmer@umn.edu> wrote:

>
>
> On Fri, Apr 5, 2024 at 9:30 AM Ted Lemon <mellon@fugue.com> 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=
>> 40umn.edu@dmarc.ietf.org> wrote:
>>
>>>
>>> On Thu, Apr 4, 2024 at 2:52 PM Brian E Carpenter <
>>> brian.e.carpenter@gmail.com> 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, internet-drafts@ietf.org 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
>>>> > I-D-Announce@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> >
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>>
>>>
>>> --
>>> ===============================================
>>> David Farmer               Email:farmer@umn.edu
>>> Networking & Telecommunication Services
>>> Office of Information Technology
>>> University of Minnesota
>>> 2218 University Ave SE        Phone: 612-626-0815
>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>> ===============================================
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>
> --
> ===============================================
> David Farmer               Email:farmer@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>