class _IPv6Constants._reserved_networks should include fec0::/10

[mlnrt]

Bug report

This is a follow-up of: #136794

Bug description:

IPv6 address block fec0::/10 has been deprecated in 2004 as a "Site-Local scoped address prefix" and is now a `` (see Internet Protocol Version 6 Address Space and RFC 3879).

class _IPv6Constants._reserved_networks is still missing address block fec0::/10 from the list: https://github.com/python/cpython/blob/main/Lib/ipaddress.py#L2402-L2411

We should add that address block to the list and update the documentation (https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv4Address.is_reserved)

The question is do we also:

• remove the is_site_local property since according to RFC 3879, these addresses have been completely deprecated? (= breaking change)
• keep the is_site_local property to avoid breaking changes, but always return False as there is no such address block anymore?

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

[mlnrt]

I am willing to take ownership of this and write my first PEP to propose a change.

[picnixz]

• I don't think there is a need to write a PEP for that.
• For bc, I think it's better to keep the property. But if the RFC says that those are deprecated, we can simply deprecate the field itself and remove it in Python 3.17 or later (we need at least 2 versions).

[mlnrt]

@picnixz thank you for the answer. As I am just getting started with participating to cpython, I have few questions.

1. Are you suggesting to keep the property and deprecate the field or I misunderstood?
2. Why is it better to keep the property for something deprecated 21 years ago?
3. Why do we have to wait 2 versions? This is like what, 2 more years? Why do we have to wait so long for such a small technical dept clean up?

[picnixz]

1. First deprecate, then remove later.
2. Because something that has been added in the standard library may be used for something that is old. It's always a pain when we remove something because we don't know who is using it and unless we remove it, those users don't open an issue. But if it's not used a lot, or if it's against recommendations, we can deprecate and remove it.
3. Because every deprecation followed by a removal MUST have this deprecation period. This is a hard rule that is explained in PEP-387. Actually it's even 5 years now that we need to wait (before it was 2 years but the recommendation has been updated to 5 years).

What cannot be done is a breaking change between two consecutive stable versions. If the warning appears in 3.15 (and it is the soonest it can appear as 3.14 is feature-locked), we can remove the attribute in 3.17 or later.

[mlnrt]

@picnixz thank you for the clarification, but then it's not for me.