On Sat, Sep 26, 2009 at 4:27 PM, Daniel Stutzbach
<dan...@stutzbachenterprises.com> wrote:
> On Sat, Sep 26, 2009 at 4:57 PM, DrKJam <drk...@gmail.com> wrote:
>>
>> 2009/9/26 Daniel Stutzbach <dan...@stutzbachenterprises.com>
>>>
>>> On Sat, Sep 26, 2009 at 2:07 PM, DrKJam <drk...@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.
I'll call this out in the PEP if necessary. As mentioned elsewhere,
classful addressing is so long deprecated that I would expect it to
cause confusion if it was assumed.
>>> 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.
-(1/0) forcing a user to include a prefixlen when creating a network
object doesn't actually serve any useful purpose. when dealing with
network objects, it's very useful (and common) to assume a /32 prefix
length when none is supplied.
Cheers,
/peter
> --
> Daniel Stutzbach, Ph.D.
> President, Stutzbach Enterprises, LLC
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
