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

[Nick Buraglio <[e-mail]>]

I went back through and it looks like this snuck back in between v20
and v21, an oversight on my part.

In section 5.3:

OLD:

5. ULA interface addresses from within fd00::/8, particularly ones not
created by SLAAC, and not already covered by the known-local ULA list
MUST be added to the list with an assumed prefix length of /48.
However, as with rule 1, if the ULA interface address was generated on
the basis of a PIO that has only been seen in RAs in which the SNAC
router flag bit is set, this ULA prefix MUST NOT be used as described
in this rule (rule 5). This prevents potential use of a non-routable
source address when communicating to a known-local ULA destination
address that is not on the local link, as SNAC-generated GUAs can only
work on a single link, and the only reason to ever choose them in
source address selection is that the only choice for a destination
address is the longest prefix match.

6. Regardless of their length or how the PIO flags are set, other PIOs
from within fd00::/8 that are not already covered by the known-local
ULA list MAY be added to the list, but only with the advertised prefix
length.

7. When inserting known-local ULA entries into the policy table, they
MUST have a label of 14 (rather than the default ULA label of 13) and
a precedence of 45.


NEW:


5. ULA interface addresses from within fd00::/8, particularly ones not
created by SLAAC, and not already covered by the known-local ULA list
MUST be added to the list with an assumed prefix length of /48.
However, as with rule 1, if the ULA interface address was generated on
the basis of a PIO that has only been seen in RAs in which the SNAC
router flag bit is set, this ULA prefix MUST NOT be used as described
in this rule (rule 5). This prevents potential use of a non-routable
source address when communicating to a known-local ULA destination
address that is not on the local link, as SNAC-generated GUAs can only
work on a single link, and the only reason to ever choose them in
source address selection is that the only choice for a destination
address is the longest prefix match.

6. When inserting known-local ULA entries into the policy table, they
MUST have a label of 14 (rather than the default ULA label of 13) and
a precedence of 45.


On Sun, Jun 29, 2025 at 5:35 PM Bob Hinden <[e-mail]> wrote:
>
> Nick,
>
> Please send the proposed change here clearly showing the change, like old text, new text, before publishing a new draft.  It needs review since this is happening after the IESG approval and I think it is more than can be done in AUTH48.
>
> Bob
>
>
>
>
> On Jun 29, 2025, at 10:23 AM, Nick Buraglio <[e-mail]> wrote:
>
> Thanks for catching this, it definitely got missed in the IETG updates we made, and I agree that it should be specified more succinctly in accordance with what the WG agreed on. I can submit a new version fixing this, if that is the right path to go down.
>
> nb
>
>
> On Sat, Jun 28, 2025 at 10:12 PM Lorenzo Colitti <[e-mail]> wrote:
>>
>> On Tue, Jun 24, 2025 at 7:22 AM <[e-mail]> wrote:
>>>
>>>    Title:   Prioritizing known-local IPv6 ULAs through address selection policy
>>>    Authors: Nick Buraglio
>>>             Tim Chown
>>>             Jeremy Duncan
>>>    Name:    draft-ietf-6man-rfc6724-update-21.txt
>>
>>
>> Authors, chairs, ADs (since this went to the IESG last week).
>>
>> I just took a look at the latest version and it looks like the following text went in to -21 just before the document was reviewed by the IESG:
>>
>> ====
>>    6.  Regardless of their length or how the PIO flags are set, other
>>        PIOs from within fd00::/8 that are not already covered by the
>>        known-local ULA list MAY be added to the list, but only with the
>>        advertised prefix length.
>> ====
>>
>> This text is problematic because it allows a host to consider, for example, a PIO for "fd00::/8" with L=0 and A=0 as known-local. Such behaviour would completely defeat the purpose of known-local ULAs, because it would treat all of ULA space as local. In the WG there was very substantial discussion on this point and that discussion ultimately led to the consensus text of saying that by default known-local ULAs are /48 and MUST NOT be shorter than /40. Allowing arbitrary prefix lengths, even as a MAY, undermines that consensus. Worse, by leaving it up to the implementation, it leads to fragmentation.
>>
>> I don't think this sort of substantial change should be made after WGLC. Can we remove this text?
>>
>> Or, if this text was added to solve a concrete problem, then can we limit this behaviour to prefix lengths between /40 and /48?
>>
>> Thanks,
>> Lorenzo
>
>