[Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

["Martin v. Löwis"]

> IPv6Address.is_ipv4_compat
> IPv6Network.is_ipv4_compat
> 
> 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.is_ipv4_mapped
> IPv6Network.is_ipv4_mapped
> 
> 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.is_reserved
> IPvXNetwork.is_reserved
> 
> 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.is_unicast    
> IPvXNetwork.is_unicast
> 
> 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 summarize_address_range()
> 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(ipv4_mapped=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 collapse_address_list() this
> could be handy and fast.

So when talking about it, please provide use cases.

Regards,
Martin