[Python-Dev] PEP 3144 review.

[Daniel Stutzbach]

On Sat, Sep 26, 2009 at 4:57 PM, DrKJam <drkjam at gmail.com> wrote:

> 2009/9/26 Daniel Stutzbach <daniel at stutzbachenterprises.com>
>
>> On Sat, Sep 26, 2009 at 2:07 PM, DrKJam <drkjam at gmail.com> wrote:
>>
>>> The current version of the PEP and reference implementation do not
>>> mention or deal with IPv4 classful addressing (A, B, C, D and E). It would
>>> be good to know if any of this (admittedly older yet no less important)
>>> functionality is going to be supported. If the library is to concentrate
>>> solely on classless addressing (i.e. CIDR) please can this be stated in
>>> future revisions of the PEP.
>>>
>>
>> Classful addressing was deprecated more than 15 years ago!
>>
>> Quoting RFC 4632: "With the full deployment of CIDR on the Internet, such
>> scenarios are no longer operationally relevant."
>
>
> Interesting as evidence of classful IPv4 behaviour seems fairly pervasive
> in current IP stacks and software that supports IPv4 addressing (e.g.
> PostgreSQL inet and cidr data types).
>

PostgreSQL's inet type stores a host address and optionally a network mask.
It's cidr type stores a network address and mask.  Neither of them are
classful.


> Here's an excerpt from the 'ifconfig' man page (taken from an Ubuntu 9.04
> install) :-
> netmask addr
>
> Set the IP network mask for this interface. This value defaults to the
> usual class A, B or C network mask (as derived from the interface IP
> address). but it can be set to any value.
>

Since the network mask can be set to any legal value, that means it's stored
as CIDR.  It falls back on the classful network mask as a default.
Undoubtedly that was useful when ifconfig was updated for CIDR.  There were
still many classful networks and it needed to retain backward
compatibility.  After all, ifconfig is around 25 years old, and CIDR is only
16.

Today, all IP networks are classless (CIDR), and a system administrator
would have to do extra work to figure out if the default value happened to
be just right for the network they're setting up.


>  The point being that you can't always assume /32 implicitly for all use
> cases.
>

Certainly, which is why the user can explicitly set the netmask.


> Here is how IP addresses without an explicit prefix or netmask are
> currently handled :-
>
> >>> import ipaddr
> >>> ipaddr.IPv4Network('10.0.0.1')
> IPv4Network('10.0.0.1/32')
>
> It may not be something we want to support (you could always force the end
> user to specify a prefix or netmask explicitly). This is fair enough, but
> let's indicate that it's a considered choice. Somewhere in the PEP text is
> might be a good place for treatment of this topic.
>

+1 on forcing the user to specify a netmask explicitly and documenting it.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090926/4d5d5d38/attachment.htm>