[IPv6]Re: RFC 4291 and Site-Local Addressing

[David Farmer <[e-mail]>]

I guess my question is: What is the intent of any change?

Here are my thoughts;

1. I don't think fec0::/10 should ever be returned to the available IPv6
pool.
2. It is currently listed in the IPv6 Address Space Registry but not the
IPv6 Special Purpose Address Registry. Maybe it should be added to the
latter with a reference to the termination date list as the date of RFC3879.

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

3. It is in the RFC6724 Default Policy Table with the lowest possible
priority, which ensures any other address will be preferred, which I
believe is our intention. If removed, they would be treated as GUA, which I
don't believe is our intention.
4. They could be removed from an updated RFC4291 and likely ULA added in
their place. However, I don't see this issue driving an update to RFC4291.
As mentioned, there has been a lack of consensus on updating RFC4291.


Thanks.

On Fri, Nov 1, 2024 at 12:19 PM Kyle Ouellette <[e-mail]>
wrote:

> Hi Jeremy,
>
> I don't know. I think a small section saying "this was once a thing, don't
> do it anymore" isn't harmful and doesn't necessarily need to be removed but
> that's just my opinion.
>
> Why would it be a failed test if another GUA was configured on the
> interface? If the destination address is fec0::/10 and the node has two
> source addresses, one fec0::/10 and some other GUA, the fec0::/10 address
> should be used as the source because of rule 6.
>
> Thanks,
> Kyle
>
> On Fri, Nov 1, 2024 at 10:47 AM Jeremy Duncan <[e-mail]>
> wrote:
>
>> Kyle-
>>
>>
>>
>> 4291 has been in place as is and 3879 has deprecated site local
>> addressing for 20 years. How much longer should it be in this state?
>>
>>
>>
>> Also, the policy table would cause a failed test case if there happened
>> to be another Global Unicast Address on the interface. Because it will use
>> the GUI instead of the site local based on the prefix policy table.
>>
>>
>>
>>
>>
>> -Jeremy
>>
>>
>>
>> *From:* Kyle Ouellette <[e-mail]>
>> *Sent:* Thursday, October 31, 2024 4:45 PM
>> *To:* Jeremy Duncan <[e-mail]>
>> *Cc:* [e-mail]
>> *Subject:* Re: [IPv6]RFC 4291 and Site-Local Addressing
>>
>>
>>
>> [EXTERNAL] Verify links and attachments with sender.
>>
>> Hi Jeremy,
>>
>>
>>
>> Yes, I see your point about the policy table. Is there harm in leaving
>> 4291 2.5.7 more for historical purposes? New implementations shouldn't
>> apply special behavior to the fec0::/10 prefix, but should 4291 continue to
>> be verbose about this?
>>
>>
>>
>> As for the AA 1.5 tests, they're not fully redundant. They provide checks
>> to ensure implementations don't interpret RFC 3879 as a "drop".
>>
>>
>>
>> Thanks,
>> Kyle
>>
>>
>>
>> On Thu, Oct 31, 2024 at 1:50 PM Jeremy Duncan <
>> [e-mail]> wrote:
>>
>> Kyle-
>>
>>
>>
>> Not a problem per se. Just that if someone were to implement site local
>> addressing in their network, the prefix policy tables would not treat it as
>> global unicast addressing. It would treat it in precedence below IPv4, ULA,
>> etc.
>>
>>
>>
>> So I’m asking if the 6man would like to take up a full deprecation of
>> site local addressing to remove it from 4291 and potentially 6724.
>>
>>
>>
>> In relation to the AA 1.5 tests, if the intent is to test it as GUI, then
>> it’s a redundant test right?
>>
>>
>>
>>
>>
>> -Jeremy
>>
>>
>>
>> *From:* Kyle Ouellette <[e-mail]>
>> *Sent:* Thursday, October 31, 2024 1:42 PM
>> *To:* Jeremy Duncan <[e-mail]>
>> *Cc:* [e-mail]
>> *Subject:* Re: [IPv6]RFC 4291 and Site-Local Addressing
>>
>>
>>
>> [EXTERNAL] Verify links and attachments with sender.
>>
>> Hi Jeremy,
>>
>>
>>
>> I'm not sure I understand the problem you're describing and how it
>> relates to the AA 1.5 tests. Can you provide more details on the problem
>> you're facing?
>>
>>
>>
>> Thanks,
>> Kyle
>>
>>
>>
>> On Wed, Oct 30, 2024 at 5:05 PM Jeremy Duncan <
>> [e-mail]> wrote:
>>
>> Kyle, thanks but Address Architecture test case 1.5 merely tests that
>> site local is being used. So an echo request and reply using it as the
>> source. The problem is that RFC 6724 has moved it down to precedence 1 with
>> label 11. So in essence a node conforming to 6724 would label it as a site
>> local and not a standard global unicast right?
>>
>>
>>
>>
>>
>>
>>
>> Semper Fi,
>>
>> Jeremy Duncan
>>
>> Sent from my cell
>> ------------------------------
>>
>> *From:* Kyle Ouellette <[e-mail]>
>> *Sent:* Wednesday, October 30, 2024 4:49:09 PM
>> *To:* Jeremy Duncan <[e-mail]>
>> *Cc:* [e-mail] <[e-mail]>
>> *Subject:* Re: [IPv6]RFC 4291 and Site-Local Addressing
>>
>>
>>
>> [EXTERNAL] Verify links and attachments with sender.
>>
>> Hi Jeremy,
>>
>>
>>
>> The IPv6 Ready Core tests you're referring to test that Site Local
>> addresses are deprecated and not supported. Specifically this statement
>> from 2.5.7: "The special behavior of this prefix defined in [RFC3513] must
>> no longer be supported in new implementations (i.e., new implementations
>> must treat this prefix as Global Unicast)."
>>
>>
>>
>> Thanks,
>> Kyle
>>
>>
>>
>> On Wed, Oct 30, 2024 at 4:27 PM Jeremy Duncan <jduncan=
>> [e-mail]> wrote:
>>
>> Hello 6Man-
>>
>>
>>
>> Is there any reason that Site local addressing fec0::/10 is still
>> included in RFC 4291? Since the deprecation was done back in RFC 3879 in
>> 2004, it still remains in 4291. Which also means all of the IPv6 Ready
>> conformance and interoperability testing still requires these test cases.
>>
>>
>>
>> Is there any appetite to get a bis/update in place to do a removal of
>> section 2.5.7 in RFC 4291?
>>
>>
>>
>>
>>
>> -Jeremy
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
>> --------------------------------------------------------------------
>>
>>
>>
>>
>> --
>>
>> Kyle Ouellette
>>
>> Software Development Manager, IP Technologies
>>
>> UNH InterOperability Laboratory
>>
>> 21 Madbury Rd, Suite 100, Durham, NH 03824
>>
>> [e-mail]
>>
>> www.iol.unh.edu
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Kyle Ouellette
>>
>> Software Development Manager, IP Technologies
>>
>> UNH InterOperability Laboratory
>>
>> 21 Madbury Rd, Suite 100, Durham, NH 03824
>>
>> [e-mail]
>>
>> www.iol.unh.edu
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Kyle Ouellette
>>
>> Software Development Manager, IP Technologies
>>
>> UNH InterOperability Laboratory
>>
>> 21 Madbury Rd, Suite 100, Durham, NH 03824
>>
>> [e-mail]
>>
>> www.iol.unh.edu
>>
>>
>>
>>
>>
>
> --
>
> Kyle Ouellette
>
> Software Development Manager, IP Technologies
>
> UNH InterOperability Laboratory
>
> 21 Madbury Rd, Suite 100, Durham, NH 03824
>
> [e-mail]
>
> www.iol.unh.edu
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> --------------------------------------------------------------------
>


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