Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

[Lorenzo Colitti <[e-mail]>]

I have an implementation for Android that's not quite finished but mostly
works. It's much more work than it would be on plain linux systems because
glibc already supports most of this and Android didn't.

   - DNS resolver: https://android-review.googlesource.com/3046000 and
   dependencies
   - Label insertion code: https://android-review.googlesource.com/3043004
   and dependencies .

The IP address monitoring code keeps track of local ULAs on the interface
and uses netlink commands to associate label 14 with known-local ULA
prefixes on that interface. This is probably similar to what Brian's code
does, though I haven't looked at it. When the DNS resolver evaluates a ULA
for destination address selection, it will query the kernel for the address
label of ULA addresses on the interface it will use for the DNS query, and
if it sees 14, additionally ups the precedence. This is a bit of a shortcut
that avoids the need to track known-local ULAs in both userspace and
kernel. After that it runs the existing RFC6724 algorithm.

This approach has a race: when a new known-local ULA is added, the code
will do the wrong thing for the first few milliseconds while the label is
sent to the kernel, but after that it will behave correctly. I don't think
this matters too much, but if it does, it can be fixed by adding kernel
code to set the label correctly (which would also make it easier to
implement this on other Linux systems).

On Wed, Apr 24, 2024 at 4:58 PM David Farmer <farmer=
[e-mail]> wrote:

> Ok then, I support this document moving forward with a MUST for inserting
> known-local ULAs and other changes. However, with that as a MUST, I'd
> really like to see at least some proof of concept running code that
> demonstrates we have a good specification for achieving the insertion of
> known-local ULAs.
>
>    1. The definition of known-local ULA in section 2 only includes ULAs
>    directly attached to a node. ULAs can be local without being directly
>    attached or the node having an address in the prefix. Maybe add "or
>    network" to the definition; "Known-local ULA: A ULA prefix that is
>    determined to be local to a given node or network.
>    2. If we go with MUST for known-local ULAs, we will need to revise
>    section 8. Once we know whether we are going with MUST or SHOULD, I'm happy
>    to help with this.
>    3. In Section 15, We need to add SHOULD or MUST add known-local ULAs
>    as one of the changes since RFC6724.
>
> Thanks
>
> On Wed, Apr 10, 2024 at 10:43 AM Bob Hinden <[e-mail]> wrote:
>
>> David,
>>
>> We thought so.   There was a lot of discussion and changes as a result of
>> the previous last call, the chairs thought a second last call was warranted.
>>
>> Bob
>>
>> On Apr 10, 2024, at 8:37 AM, David Farmer <[e-mail]> wrote:
>>
>> Is another last call at this time a good idea? Don't we first need to
>> resolve the SHOULD vs. MUST for the insertion of known-local ULAs? Then,
>> apply appropriate rewrites as necessary, unless you think a last call is
>> the best way to resolve that issue.
>>
>> On Wed, Apr 10, 2024 at 10:29 AM Bob Hinden <[e-mail]> wrote:
>>
>>> Given the number of changes since the first w.g. last call, the chairs,
>>> in consultation with the authors, are staring a second 6MAN working group
>>> last call for this document.
>>>
>>> This email starts a second two week 6MAN Working Group Last Call on
>>> advancing "Preference for IPv6 ULAs over IPv4 addresses in RFC6724" document
>>>
>>>     https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-update/
>>>
>>>  as a Standards Track document.
>>>
>>> A summary of changes since the -06 version is below.   A good diff to
>>> review is:
>>>
>>>
>>> https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-rfc6724-update-08&url2=draft-ietf-6man-rfc6724-update-06&difftype=--html
>>>
>>> [New draft on left due to line length problem with old draft]
>>>
>>> Substantive comments and statements of support for publishing this
>>> document should be directed to the [e-mail] mailing list.
>>> Editorial suggestions can be sent to the authors.  This last call will end
>>> on 24 April 2024 23:59 UTC.
>>>
>>> Also, one issue the authors would like feedback on is if the requirement
>>> is a SHOULD or MUST for inserting known-local ULA prefixes into their
>>> policy table with a precedence above both GUAs and IPv4, while leaving all
>>> other general ULAs at a lower precedence.  It is a SHOULD in the -08 draft,
>>> but there has been support for a MUST in the discussion.
>>>
>>> Bob, Jen, Ole
>>> 6MAN chairs
>>>
>>>
>>> Begin forwarded message:
>>>
>>> *From: *Tim Chown <Tim.Chown=[e-mail]>
>>> *Subject: **Re: [IPv6] I-D Action:
>>> draft-ietf-6man-rfc6724-update-08.txt*
>>> *Date: *April 9, 2024 at 7:47:57 AM PDT
>>> *To: *IPv6 List <[e-mail]>
>>>
>>> Hi,
>>>
>>> Actually it works better I notice with 08 on the left and 06 on the
>>> right, as -06 has the broken formatting, so please check the diff from -06
>>> to the current -08 using:
>>>
>>>
>>> https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-rfc6724-update-08&url2=draft-ietf-6man-rfc6724-update-06&difftype=--html
>>>
>>> The changes are largely around making the MAY insert local entries into
>>> a SHOULD insert known-locals, with a little more text on how we’d determine
>>> those.
>>>
>>> Tim
>>>
>>> On 9 Apr 2024, at 15:13, Nick Buraglio <[e-mail]>
>>> wrote:
>>>
>>> We have published -08 of the rfc6724 update, this fixes some
>>> formatting and other typographical oversights
>>> The following sections address comments from the lis (difft from -06
>>> to -08 is the most useful comparison):
>>>
>>> https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-rfc6724-update-06&url2=draft-ietf-6man-rfc6724-update-08&difftype=--html
>>>
>>>
>>> Brief overview of the changes from -06:
>>>
>>> Section 2:
>>> Add terminology section and define known-local
>>>
>>> Section 3:
>>> Add section on elevating
>>> upgrades the requirement in RFC 6724 for nodes to insert a higher
>>> precedence entry in the policy table for observed ULA prefixes that
>>> are known to be local, referred to in this document as "known-local"
>>> ULAs, from a MAYto a SHOULD.
>>>
>>> Section 4:
>>> Changes the 6to4 prefix deprecation to match Teredo, adds further
>>> clarity and reference to RFC6724 section 10.7
>>>
>>> Section 5:
>>> Add text to upgrade the requirement to automatically insert
>>> known-local ULAs into a node's policy table from a MAY to a SHOULD.
>>>
>>> Section 5.3
>>> Further define insertion and removal parameters and requirements for
>>> known-local ULA prefixes into table and associated values and label
>>>
>>> Section 7.2:
>>> Further clarify GUA-GUA preferred over ULA-ULA details
>>>
>>> Section 7.3:
>>> Further clarify ULA-ULA preferred over IPv4-IPv4 details
>>>
>>> Section 8:
>>> Housekeeping and formatting changes
>>>
>>> Section 9.2:
>>> Describe the new known-local interaction and how it addresses issues
>>> with ULAs in global DNS
>>>
>>>
>>>
>>> Further copy edit and housekeeping.
>>>
>>> Thanks!
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>>
>>> --------------------------------------------------------------------
>>> 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
>> ===============================================
>>
>>
>>
>
> --
> ===============================================
> 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
> --------------------------------------------------------------------
>