[issue17400] ipaddress.is_private needs to take into account of rfc6598

Changes by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Freek Dijkstra added the comment: Peter, first of all, thanks for your library. I didn't mention that before, but should have. I'm in favour of a pragmatic approach. I've only come across NATing for RFC 1918 and RFC 6598 addresses. While it can technically be done for other addresses, and is

[issue17400] ipaddress.is_private needs to take into account of rfc6598

pmoody added the comment: is_private was, as you note, basically shorthand for is_RFC1918 (and is_RFC4193 for v6). It's not a particularly well-named method, but at the time that I wrote it (~5 years ago?), it did what I needed it to do. I'm not sure what you mean by an 'is_natted()' method; t

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Freek Dijkstra added the comment: A bit odd questions: What is the is_private() function intended to accomplish? I have been wondering what is_private() means, and how users of the library are going to use this function. I've actually failed to come up with any sensible use-case with the curre

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Freek Dijkstra added the comment: Edit: could you rephrase? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Freek Dijkstra added the comment: 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." -- ___ Python tracker ___

[issue17400] ipaddress.is_private needs to take into account of rfc6598

pmoody added the comment: 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.

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Freek Dijkstra added the comment: 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()

[issue17400] ipaddress.is_private needs to take into account of rfc6598

pmoody added the comment: 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. Howe

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Lei Miao added the comment: 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 wrote: > > pmoody added the comment: > > Is the request that is_private s

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Terry J. Reedy added the comment: 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. -- nosy: +ncoghlan, terry.reedy ___ Python tracker

[issue17400] ipaddress.is_private needs to take into account of rfc6598

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 yea

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Lei Miao added the comment: Thanks Peter. On 13 March 2013 03:35, pmoody 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 track

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Changes by Santoso Wijaya : -- nosy: +santa4nt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue17400] ipaddress.is_private needs to take into account of rfc6598

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 ___ __

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Christian Heimes added the comment: 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/wik

[issue17400] ipaddress.is_private needs to take into account of rfc6598

Changes by Jesús Cea Avión : -- nosy: +jcea versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue17400] ipaddress.is_private needs to take into account of rfc6598

New submission from Lei Miao: 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 we