hello, On Thu, 22 Mar 2007, "Martin v. Löwis" wrote:
| >Would it be out of the question to change the IPv6 address 4-tuple to | >a 2-tuple (as used with IPv4) in Python 2.0? This is a source of many | >compatibility problems, and the additional flowinfo and scope elements | >from the IPv6 tuple are practically never used by normal applications. | | As a starting point of any discussion, you should get into contact with | the author of the IPv6 support in Python, Jun-ichiro "itojun" Hagino. Attached is a reply I got from itojun when asking about this. For those that don't know about IPv6 scoped addresses: there are 1. global addresses, which are the ones you normally use for everything 2. link-local addresses, which work on just one L2 layer, they are used for things like neighbour advertisements which replaces ARP, and DHCP 3. site-local addresses, which were deprecated some time ago and were an abandoned attempt to replace IPv4 RFC1918 addressing (the current way is randomly generated prefixes used with global scope, RFC4193) I first suggested just chopping off the flowid and scopeid parts of the tuple. Itojun's reply seems to indicate we could potentially get away with merging the scopeid to the IP address part in a standard fashion, and discarding the flowid part. In the below mail to itojun I suggested also an alternative way of accepting both the 2-tuple and 4-tuple kinds of objects for IPv6. The socket api would return 2-tuples for scope=global flowid=0 addresses, and 4-tuples for others. Another option that came to my mind is changing the address object from tuple to an object with named fields. This way IPv4 and IPv6 address compatibility could be taken care of with duck typing. This would also require changing the way IPv4 addresses work, but now feels to me like the most clean solution. -- erno
--- Begin Message ---> Hello, > > Enclosed is a message exchange I had on the python-3000 list (in > which I mistyped Python 2.0 instead of Python 3.0). > > I'd like to see the IPv6 address tuple in Python 3000 aka Python 3.0 > changed to be (adddress, port) so that socket code written for > IPv4 would work with it. The 4-tuple with additional flowinfo and scopeid > elements in my opinion isn't worth it compared to the hardship caused. > Another approach could be to allow both 2-tuple and 4-tuple, and > always generate a 2-tuple for global addresses without flowinfo... > What is your take on this proposal? i understand your concern. current 4-tuple is direct mapping from struct sockaddr_in6 (which has those two additional members). scopeid element is very important and we cannot just drop it. IPv6 includes "scoped" addresses, i.e. you may see the same address (fe80::1) on two of your ethernets, and they are different entity, therefore you need to disambiguate with scopeid (usually interface name). luckily there is a way to handle address+scopeid as single string - see RFC4007 section 11. this way, we can remove scopeid field. noone uses flowinfo at this point of time (it is for QoS - diffserv, intserv, and that kind of stuff) but i'm not sure about future use. please discuss it with python guys (cc: to me if needed). as for actual code change, i'm willing to help but i got my right hand injured so i can't work on anything seriously for a couple of weeks. please keep me posted. itojun
--- End Message ---
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
