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

[Jeremy Duncan <[e-mail]>]

Kyle-
First, Sec 4 specifically says it should not be reused for GUI or any other purposes anyway

“The prefix MUST NOT be reassigned for other use
   except by a future IETF standards action.  Future versions of the
   addressing architecture [RFC3513<https://datatracker.ietf.org/doc/html/rfc3513>] will include this information
”

So outside of RFC updates, AA1.5 for conformance and interop should get removed because it’s being used for something other than site-local right?

And yes, you’re right about rule 6, my bad.


-Jeremy

From: Kyle Ouellette <[e-mail]>
Sent: Friday, November 1, 2024 1:17 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 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]