Improve the textual representation of IPv4-mapped IPv6 addresses

[maxmouchet]

BPO	43633
Nosy	@opavlyuk, @maxmouchet
PRs	gh-87799: Improve the textual representation of IPv4-mapped IPv6 addresses #29345

^{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 = None
created_at = <Date 2021-03-26.17:34:40.530>
labels = ['type-feature', 'library']
title = 'Improve the textual representation of IPv4-mapped IPv6 addresses'
updated_at = <Date 2021-11-01.12:05:04.773>
user = 'https://github.com/maxmouchet'

bugs.python.org fields:

activity = <Date 2021-11-01.12:05:04.773>
actor = 'opavlyuk'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-03-26.17:34:40.530>
creator = 'maxmouchet'
dependencies = []
files = []
hgrepos = []
issue_num = 43633
keywords = ['patch']
message_count = 2.0
messages = ['389556', '405434']
nosy_count = 2.0
nosy_names = ['opavlyuk', 'maxmouchet']
pr_nums = ['29345']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue43633'
versions = []

[maxmouchet]

Python supports IPv4-mapped IPv6 addresses as defined by RFC 4038:
"the IPv6 address ::FFFF:x.y.z.w represents the IPv4 address x.y.z.w.”

The current behavior is as follows:

   from ipaddress import ip_address
   addr = ip_address('::ffff:8.8.4.4') # IPv6Address('::ffff:808:404')
   addr.ipv4_mapped # IPv4Address('8.8.4.4')

Note that the textual representation of the IPv6Address is *not* in IPv4-mapped format.
It prints ::ffff:808:404 instead of ::ffff:8.8.4.4.
This is technically correct, but it’s somewhat frustrating as it makes it harder to read IPv4s embedded in IPv6 addresses.

My proposal would be to check, in __str__, if an IPv6 is an IPv4-mapped, and to return the appropriate representation :

   from ipaddress import ip_address
   addr = ip_address('::ffff:8.8.4.4')

   # Current behavior
   str(addr)  # '::ffff:808:404'
   repr(addr) # IPv6Address('::ffff:808:404')

   # Proposed behavior
   str(addr)  # '::ffff:8.8.4.4'
   repr(addr) # IPv6Address('::ffff:8.8.4.4')

A few data points:

• Julia prints ::ffff:808:404 (current behavior)
• C (glibc) and ClickHouse prints ::ffff:8.8.4.4 (proposed behavior)

[opavlyuk]

@maxmouchet, thank you for creating the issue.
For me it makes sense, and RFC 4291 calls such IPv6 text representation approach as "more convenient".

I'll try to fix this, if you don't mind.
P.S.: Sorry for providing PR before I asked.

[asvetlov]

Done by #29345

[kellyjonbrazil]

Are there any tests for the reverse_pointer method? I'm seeing strange results with the new behavior:

IP Address: ::FFFF:192.168.1.35

Results in a reverse_pointer of:

5.3...1...8.6.1...2.9.1.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa

instead of the old:

3.2.1.0.8.a.0.c.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa

I'm not sure which one is more valid or if a pointer record is even relevant in the context of mapped addresses. The original way seems more correct to me if nothing for the fact that there are strange extra dots in the new output.

(I'll create a new issue for this since this one is closed)