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

[Jeremy Duncan <[e-mail]>]

Bob-

Thanks, I would agree with that.  But could that 3879 bis also be categorized as an update to 4291? That way any implementation/compliance linkage to 4291 would have that traceability.


-Jeremy


From: Bob Hinden <[e-mail]>
Sent: Friday, November 1, 2024 4:21 PM
To: Jeremy Duncan <[e-mail]>
Cc: Bob Hinden <[e-mail]>; David Farmer <[e-mail]>; IPv6 List <[e-mail]>
Subject: Re: [IPv6]Re: RFC 4291 and Site-Local Addressing

Jeremy,


On Nov 1, 2024, at 7:51 PM, Jeremy Duncan <jduncan=[e-mail]<mailto:jduncan=[e-mail]>> wrote:

David-

Highlighting again how 3879 was published in *2004* – if there are “existing implementations” using site-local addressing I guess that means we should start accommodating unsupported 20-year old OS/network stacks in all of our IPv6 standards discussions?

Does that sentence even apply now?

And I don’t agree that there’s a balance to be struck here.  Because this is what stack implementations are doing as we speak not familiar with all of this crazy nuance: building in support to configure, pass, and implement site-local addressing because it is still part of RFC 4291. So they do this because they want to claim compliance with 4291. Then they go for a USGv6 (or other type IPv6) certification and have to meet site-local addressing requirements.

We are all saying and doing both things at once. Let’s just do a bis on 4291 and fix this mess.

Instead of resurrecting RFC4291bis, another approach would be to do a bis of RFC3879.   I assume the biggest change would be to make the deprecation stronger.  For example change:

   Existing implementations and deployments MAY continue to use this
   prefix.

s/MAY continue/MUST NOT continue/

Bob






-Jeremy

From: David Farmer <[e-mail]<mailto:[e-mail]>>
Sent: Friday, November 1, 2024 3:38 PM
To: Jeremy Duncan <[e-mail]<mailto:[e-mail]>>
Cc: Kyle Ouellette <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [IPv6]Re: RFC 4291 and Site-Local Addressing

[EXTERNAL] Verify links and attachments with sender.
It is not quite that simple;

In RFC3484, Site Local has a preference because of its scope; RFC6724 removed that, but per Appendix B #3;

Added a row for site-local addresses (fec0::/10) in order to depreference them, for consistency with the example in Section 10.3, since they are deprecated [RFC3879].

I think that is correct. The scope preference was removed, and adding the entry allowed it to be dereferenced, which is consistent with "deprecated."

Also, immediately following the paragraph you Quoted, it says;

Existing implementations and deployments MAY continue to use this prefix.

Given that they can continue to exist, I think RFC6724 has the correct balance.

In other words, Site Local has been deprecated, as in "SHOULD NOT be used. " It has not been made Historical, AKA killed, shot dead, or exterminated. Maybe we should send the Daleks after Site Local addresses, "EXTERMINATE!, EXTERMINATE!" But we haven't done that yet.

Thanks

On Fri, Nov 1, 2024 at 2:09 PM Jeremy Duncan <[e-mail]<mailto:[e-mail]>> wrote:
So, should we not follow the very explicit recommendation in the Deprecation section - sec 4 of 3879?

“The references to site local addresses should be removed as soon as
   practical from the revision of the Default Address Selection for
   Internet Protocol version 6 [RFC3484<https://datatracker.ietf.org/doc/html/rfc3484>] the revision of the Basic
   Socket Interface Extensions for IPv6 [RFC3493<https://datatracker.ietf.org/doc/html/rfc3493>] and from the revision
   of the Internet Protocol Version 6 (IPv6) Addressing Architecture
   [RFC3513<https://datatracker.ietf.org/doc/html/rfc3513>]  Incidental references to site local addresses should be
   removed from other IETF documents if and when they are updated.
   These documents include [RFC2772, RFC2894<https://datatracker.ietf.org/doc/html/rfc2894>, RFC3082<https://datatracker.ietf.org/doc/html/rfc3082>, RFC3111<https://datatracker.ietf.org/doc/html/rfc3111>, RFC3142<https://datatracker.ietf.org/doc/html/rfc3142>,
   RFC3177<https://datatracker.ietf.org/doc/html/rfc3177>, and RFC3316<https://datatracker.ietf.org/doc/html/rfc3316>].”

Is 20 years not “as soon practical?” – that is specifically calling out 6724 and 4291 (even though those are even older RFCs)
It’s getting a little hard to talk about the cutting edge of IPv6 when we have all these “hanging chads” in the standards.

Between, site-local, mobile IPv6, and SeND we have a bunch of things that have no implementation but plenty of standards.

There’s no wonder implementations get confused.


-Jeremy

From: David Farmer <[e-mail]<mailto:[e-mail]>>
Sent: Friday, November 1, 2024 2:38 PM
To: Kyle Ouellette <[e-mail]<mailto:[e-mail]>>
Cc: Jeremy Duncan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [IPv6]Re: RFC 4291 and Site-Local Addressing

[EXTERNAL] Verify links and attachments with sender.
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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Thursday, October 31, 2024 4:45 PM
To: Jeremy Duncan <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Thursday, October 31, 2024 1:42 PM
To: Jeremy Duncan <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Wednesday, October 30, 2024 4:49:09 PM
To: Jeremy Duncan <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
www.iol.unh.edu
<http://www.iol.unh.edu/>

[https://lh3.googleusercontent.com/OTrJdJXV8tCIMAYCPVPX-NQFR3bbQkx2aHrNrXnAflhSLOanj-H5Nis9g4EjaDh0JEWqJtys-N79aBudaXuVBUY88tngeMFg9dvkTXr2fKwnyOmWgsPy1E6IAVm3kCMxK1sBvVDu]



--
Kyle Ouellette
Software Development Manager, IP Technologies
UNH InterOperability Laboratory
21 Madbury Rd, Suite 100, Durham, NH 03824

[e-mail]<mailto:[e-mail]>
www.iol.unh.edu
<http://www.iol.unh.edu/>

[https://lh3.googleusercontent.com/OTrJdJXV8tCIMAYCPVPX-NQFR3bbQkx2aHrNrXnAflhSLOanj-H5Nis9g4EjaDh0JEWqJtys-N79aBudaXuVBUY88tngeMFg9dvkTXr2fKwnyOmWgsPy1E6IAVm3kCMxK1sBvVDu]



--
Kyle Ouellette
Software Development Manager, IP Technologies
UNH InterOperability Laboratory
21 Madbury Rd, Suite 100, Durham, NH 03824

[e-mail]<mailto:[e-mail]>
www.iol.unh.edu
<http://www.iol.unh.edu/>

[https://lh3.googleusercontent.com/OTrJdJXV8tCIMAYCPVPX-NQFR3bbQkx2aHrNrXnAflhSLOanj-H5Nis9g4EjaDh0JEWqJtys-N79aBudaXuVBUY88tngeMFg9dvkTXr2fKwnyOmWgsPy1E6IAVm3kCMxK1sBvVDu]



--
Kyle Ouellette
Software Development Manager, IP Technologies
UNH InterOperability Laboratory
21 Madbury Rd, Suite 100, Durham, NH 03824

[e-mail]<mailto:[e-mail]>
www.iol.unh.edu
<http://www.iol.unh.edu/>

[https://lh3.googleusercontent.com/OTrJdJXV8tCIMAYCPVPX-NQFR3bbQkx2aHrNrXnAflhSLOanj-H5Nis9g4EjaDh0JEWqJtys-N79aBudaXuVBUY88tngeMFg9dvkTXr2fKwnyOmWgsPy1E6IAVm3kCMxK1sBvVDu]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
--------------------------------------------------------------------


--
===============================================
David Farmer               Email:[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
--------------------------------------------------------------------