ipaddress should make it easy to identify rfc6598 addresses

[leim]

BPO	17400
Nosy	@terryjreedy, @jcea, @ncoghlan, @pitrou, @macfreek, @tiran
Files	issue.17400.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-11-03.12:37:43.282>
created_at = <Date 2013-03-12.01:36:56.910>
labels = ['type-feature', 'library']
title = 'ipaddress should make it easy to identify rfc6598 addresses'
updated_at = <Date 2013-11-03.12:37:43.281>
user = 'https://bugs.python.org/leim'

bugs.python.org fields:

activity = <Date 2013-11-03.12:37:43.281>
actor = 'ncoghlan'
assignee = 'none'
closed = True
closed_date = <Date 2013-11-03.12:37:43.282>
closer = 'ncoghlan'
components = ['Library (Lib)']
creation = <Date 2013-03-12.01:36:56.910>
creator = 'leim'
dependencies = []
files = ['31851']
hgrepos = []
issue_num = 17400
keywords = ['patch']
message_count = 31.0
messages = ['184002', '184019', '184031', '184052', '184249', '184258', '184260', '184334', '195550', '195568', '195607', '195608', '195612', '195852', '195979', '196081', '196320', '196323', '198326', '200847', '200852', '200853', '200854', '200938', '200967', '200984', '200985', '200989', '200990', '201157', '202020']
nosy_count = 10.0
nosy_names = ['terry.reedy', 'jcea', 'ncoghlan', 'pitrou', 'macfreek', 'christian.heimes', 'pmoody', 'santoso.wijaya', 'python-dev', 'leim']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue17400'
versions = ['Python 3.4']

[leim]

Currently: ipaddress.IPv4Network('100.64.1.0/24').is_private == False

Given RFC6598, 100.64.0.0/10 is now approved for use as CGN space, and also for rfc1918-like private usage. Could the code be altered so that is_private will return true for 100.64.0.0/10 as well??

[tiran]

According to Wikipedia [1] even more address ranges are reserved and non-routable. But only three address ranges are marked as private. So 100.64.0.0/10 is reserved and non-routable but not considered a private address range.

[1] http://en.wikipedia.org/wiki/Reserved_IP_addresses

[pmoody]

I don't see anyway to actually assign this bug to myself, but I'll get a patch for this.

[leim]

Thanks Peter.

On 13 March 2013 03:35, pmoody <report@bugs.python.org> wrote:

pmoody added the comment:

I don't see anyway to actually assign this bug to myself, but I'll get a
patch for this.

----------
nosy: +pmoody

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue17400\>

---

[pmoody]

Is the request that is_private should return true for all reserved/non-routable addresses? The docstrings refer to specific rfcs which don't cover most of the addresses listed in the wikipedia page. I haven't done a lot of network programming in the last couple of years, so what do folks think the least surprising result here would be?

[terryjreedy]

Peter, 'Assigned To' is a developer who intends to push (or has pushed) a patch. Anyone can write and attach one. And it is nice to give notice that you intend to.

[leim]

is_private should return true for all prefixes that are intended for
*private* use, hence it should include rfc1918 and rfc6598. rfc6598
stipulates 100.64.0.0/10

On 16 March 2013 06:34, pmoody <report@bugs.python.org> wrote:

pmoody added the comment:

Is the request that is_private should return true for all
reserved/non-routable addresses? The docstrings refer to specific rfcs
which don't cover most of the addresses listed in the wikipedia page. I
haven't done a lot of network programming in the last couple of years, so
what do folks think the least surprising result here would be?

----------

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue17400\>

---

[pmoody]

So I'm not convinced that 6598 space should be treated like 1918 space. Specifically, the second paragraph of the rfc states:

Shared Address Space is distinct from RFC 1918 private address space
because it is intended for use on Service Provider networks.
However, it may be used in a manner similar to RFC 1918 private
address space on routing equipment that is able to do address
translation across router interfaces when the addresses are identical
on two different interfaces. Details are provided in the text of
this document.

which I read as, "It's not private like rfc1918 space, but sometimes certain people can treat it similarly." Are there more convincing arguments for treating 6598 like 1918?

[macfreek]

I was about to make the same suggestion as the OP.

Most users think of "private IP" addresses as NATed IP addresses. I think the technical term is "forwardable, but not globally unique". Thus, the method of least surprise would be that indeed the is_private() method returns True for 100.64.0.0/10.

As for the RFC, these addresses are indeed the same, that they are both NATted. They are different that for RFC 1918 addresses, it is the end-site (home network, or office network) that does the NATing, while for RFC 6598, it is the ISP that does the NATing.

I think the confusing comes from the term is_private(). Formally, this only applies to RFC 1918 addresses, but it seems that this library does not take a formal but pragmatic approach. Otherwise, they would have added the methods is_forwardable(), is_global() and is_reserved() in line with what is the official specification at http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml. I prefer a pragmatic approach, and the term is_natted() or is_private() because that is what most programmers are interested in. Those few programmers that truly understand the difference between all these IP ranges (e.g. those who write bogon filter software), will simply avoid these methods and just use the rest of the library.

So +1 for this request.

[pmoody]

I'm still not convinced. The rfc still says in essence "It's not private like rfc1918 space, but sometimes certain people can treat it similarly." and I think it would be pretty surprising for ipaddress to return True if it's not a network operator running the query. Since we have no way of knowing that, I'm extremely disinclined to make this change. A more formal solution would be all of the possible "is_RFCXXXX" methods, but that doesn't seem to be worth the effort.

[macfreek]

I don't understand your remark "I think it would be pretty surprising for ipaddress to return True if it's not a network operator running the query."

[macfreek]

Edit: could you rephrase?