[Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Fri Aug 28 02:17:54 CEST 2009

IPv6Address.isipv4compat IPv6Network.isipv4compat

Returns True if this address/network is IPv4-compatible IPv6 e.g. ::192.0.2.0 or ::192.0.2.0/124 <http://192.0.2.0/124>, False otherwise.

-1. These addresses are deprecated.

IPv6Address.isipv4mapped IPv6Network.isipv4mapped

Returns True if this address/network is IPv4-compatible IPv6 e.g. ::ffff:192.0.2.0 or ::ffff:192.0.2.0/124 <http://192.0.2.0/124>, False otherwise.

Perhaps there could be a v4_mapped function, that returned either None or a V4 address?

IPvXAddress.isreserved IPvXNetwork.isreserved

Possible list of IPv4 networks and ranges to be used for this purpose :- # IANA Reserved but subject to allocation 39.0.0.0/8 <http://39.0.0.0/8>

-1. These are merely unallocated.

128.0.0.0/16 <http://128.0.0.0/16>

-1. RFC 3330 says they are subject to allocation.

191.255.0.0/16 <http://191.255.0.0/16>

-1. It's allocated to LACNIC, for further allocation.

192.0.0.0/24 <http://192.0.0.0/24>

-1. It's allocated to ARIN; RFC 3330 says it's free for allocation.

223.255.255.0/24 <http://223.255.255.0/24>

-1. Not sure what the status is here, but RFC 3330 also lists it as available for allocation; IANA lists 223.0.0.0/8 as UNALLOCATED.

# Reserved for Future Use 240.0.0.0/4 <http://240.0.0.0/4>

+1.

# Reserved multicast 234.0.0.0 - 238.255.255.255 225.0.0.0 - 231.255.255.255

-0. What makes them different from, say, 224.0.0.0/8?

Possible list of IPv6 networks to be used for this purpose :-

FF00::/12

-1. These are multicast addresses, some in use.

::/8 0100::/8 0200::/7 0400::/6 0800::/5 1000::/4 4000::/3 6000::/3 8000::/3 A000::/3 C000::/3 E000::/4 F000::/5 F800::/6 FE00::/9

+1.

IPvXAddress.isunicast IPvXNetwork.isunicast

True if addresses or networks are within unicast ranges.

-0. What about anycast addresses?

2) An IPvXRange class (representing an arbitrary start and end IP address). This is in addition to the existing summarizeaddressrange() function.

There are use cases were an actual object representing an arbitrary range rather than a basic tuple containing two IPvXAddress objects or a list of IPvXNetwork objects is just simple to handle, more appropriate and less hassle overall. Willing to expand on the interface for this.

-0. What's use case where a tuple of two addresses wouldn't be just as good?

Basic examples :-

IPv4 -> IPv6

IPv6Address('::ffff:192.0.2.0').ipv4() IPv4Address('192.0.2.0') IPv6Address('::192.0.2.0').ipv4() IPv4Address('192.0.2.0')

-1 in this form. See above for compatible and mapped addresses. I could imaging a method trailing_ipv4, which would give an IPv4 address when all bits between 64 and 95 are 0; this would also cover cases where people put the IPv4 address into the IPv6 address using a regular prefix. Of course, this is guess-work, so the method name has to make it clear that it is guessing.

IPv4 -> IPv6

IPv4Address('192.0.2.0').ipv6() IPv6Address(::ffff:192.0.2.0') Prefer IPv4-compatible as the default (RFC 4291)

-1. These are deprecated.

IPv4Address('192.0.2.0').ipv6(ipv4mapped=True) IPv6Address('::192.0.2.0')

-0. Call it ipv4_mapped().

If there is to be an ipv6 method, it should take an IPv6Network, to allow constructing things like 2001:888:2000:d::82.94.164.162.

4) IP set based classes.

This is a big topic, so I'll save it for a subsequent post. What are the general feelings about having something like this in ipaddr? It might be deemed a little heavyweight but it is a really sweet option for the power user. Combined with the new speed of collapseaddresslist() this could be handy and fast.

So when talking about it, please provide use cases.

Regards, Martin

More information about the Python-Dev mailing list