> 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 _______________________________________________ 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
