[Python-Dev] Obsoleted RFCs
Stefan Drees
stefan at drees.name
Sat Jun 8 12:36:45 CEST 2013
On 2013-06-08 10:59, Serhiy Storchaka wrote:
> 08.06.13 11:23, Benjamin Peterson ... :
>> 2013/6/8 Serhiy Storchaka ... :
>>> Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt,
>>> *.py, *.c and *.h files. I think it would be worthwhile to update the
>>> source
>>> code and documentation for more modern RFCs.
>>
>> Just because you change the reference, doesn't mean the code is
>> automatically compliant with the updated RFC. :)
>
> Of course. Maintainers should review his modules and conclude what
> should be made for supporting more modern RFCs.
>
> I'm surprised that even new ipaddress module uses obsoleted RFC.
I for one am not :-) Let's pick that one ... as it seems to depend on
the perspective chosen (web docs vs. python code comments) (cf. Details)
Summary:
Besides the magic, that lies in the process that transforms the
documentation inside the python source into the web presented form, it
should be easy and semantically correct, to simply replace the two
occurences of "RFC 3513 2.5.6" with "RFC 4291 2.5.7".
Details:
The current web doc (3.4.0a0) at
http://docs.python.org/dev/library/ipaddress#ipaddress.IPv6Address
only shows this (no RFC3513 in sight):
"""
The following constitutes a valid IPv6 address:
1. A string consisting of ... See RFC 4291 for details. ...
"""
the current source at Lib/ipaddress.py you checked has:
# --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ----
class IPv6Network(_BaseV6, _BaseNetwork):
# ... snipped methods, reformatted, shortened ...
@property
def is_site_local(self):
"""Test if the address is reserved for site-local.
Note that the site-local address space has been
deprecated by RFC 3879.
Use is_private to test if this address is in the
space of unique local addresses as defined by RFC 4193.
Returns:
A boolean, True if the ad... is res... per RFC 3513 2.5.6.
"""
sitelocal_network = IPv6Network('fec0::/10')
return self in sitelocal_network
# --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ----
and later:
# --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ----
class IPv6Network(_BaseV6, _BaseNetwork):
# ... again snipped methods, reformatted, shortened ...
@property
def is_site_local(self):
"""Test if the address is reserved for site-local.
Note that the site-local address space has been
deprecated by RFC 3879.
Use is_private to test if this address is in the
space of unique local addresses as defined by RFC 4193.
Returns:
A boolean, True if the ad... is res... per RFC 3513 2.5.6.
"""
return (self.network_address.is_site_local and
self.broadcast_address.is_site_local)
# --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ----
The RFC 3513 (April 2003) has been obsoleted by RFC 4291 (February 2006)
and the latter has been updated by RFC 5952 (August 2010) and RFC 6052
(October 2010).
The given motivation for referencing inside the python source file is in
both cases the detailed specification of what a reserved address
actaully is.
Looking at RFC 3513 has at section 2.5.6 (the referenced one):
# --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ----
2.5.6 Local-Use IPv6 Unicast Addresses
There are two types of local-use unicast addresses defined. These
are Link-Local and Site-Local. The Link-Local is for use on a single
link and the Site-Local is for use in a single site. Link-Local
addresses have the following format:
| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+
Link-Local addresses are designed to be used for addressing on a
single link for purposes such as automatic address configuration,
neighbor discovery, or when no routers are present.
Routers must not forward any packets with link-local source or
destination addresses to other links.
Site-Local addresses have the following format:
| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111011| subnet ID | interface ID |
+----------+-------------------------+----------------------------+
Site-local addresses are designed to be used for addressing inside of
a site without the need for a global prefix. Although a subnet ID
may be up to 54-bits long, it is expected that globally-connected
sites will use the same subnet IDs for site-local and global
prefixes.
Routers must not forward any packets with site-local source or
destination addresses outside of the site.
# --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ----
The obsoleting RFC 4291 has separated the description of Link-Local and
Site-Local IPv6 Unicast adresses, thus if the section 2.5.6 reference
for the is_site_local method was correct from the start - which seems to
be a quite reasonable assumption - then the new section level reference
should be "RFC 4291 2.5.7":
# --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ----
2.5.7. Site-Local IPv6 Unicast Addresses
Site-Local addresses were originally designed to be used for
addressing inside of a site without the need for a global prefix.
Site-local addresses are now deprecated as defined in [SLDEP].
Site-Local addresses have the following format:
| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111011| subnet ID | interface ID |
+----------+-------------------------+----------------------------+
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).
Existing implementations and deployments may continue to use this
prefix.
# --- 8< ----- ------ ------- ------ ---- ------- ----- ------ ----
But there seems to be a problem when actually using Site-Local
addresses, as the new RFC (deviating from the obsoleted one) states
(c.f. above):
"""
Site-local addresses are now deprecated as defined in [SLDEP].
"""
Otherwise as a format reference all is well.
The updateing RFCs seem to not interfere with the detail pointed to (by
trusting the relation between title and content :-):
[RFC5952] "A Recommendation for IPv6 Address Text Representation"
[RFC6052] "IPv6 Addressing of IPv4/IPv6 Translators"
All the best,
Stefan.
More information about the Python-Dev
mailing list