Inability to use IPv4-mapped IPv6 on debian squeeze

Question

I have a squeeze box that I'm testing ipv6 on... eth3 is the interface... if I set up an 'normal' ipv6 address (::101:c0a8:3132/120), I see expected results in ifconfig...

eth3      Link encap:Ethernet  HWaddr 00:02:b3:9a:af:6d  
          inet6 addr: fe80::202:b3ff:fe9a:af6d/64 Scope:Link
          inet6 addr: ::101:c0a8:3132/120 Scope:Global

But if I configure an IPv4-mapped IPv6 address, I don't see part of the address...

[mpenning@hotcoffee EX4200_PC5448]$ sudo ip -6 addr del ::101:c0a8:3132/120 dev eth3
[mpenning@hotcoffee EX4200_PC5448]$ sudo ip -6 addr add ::ffff:192.168.13.236/120 dev eth3
[mpenning@hotcoffee EX4200_PC5448]$ ifconfig eth3
eth3      Link encap:Ethernet  HWaddr 00:02:b3:9a:af:6d  
          inet6 addr: 192.168.13.236/120 Scope:Global
          inet6 addr: fe80::202:b3ff:fe9a:af6d/64 Scope:Link

Shouldn't this address display as ::ffff:192.168.13.236/120 instead of 192.168.13.236/120?

I'm also having a problem pinging when the IPv4-mapped IPv6 address is assigned, so now I wonder whether this related to the unexpected display in ifconfig, or something wrong on the other side.

EDIT:

Using ip addr show eth3...

[mpenning@hotcoffee ~]$ ip addr show eth3
5: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 00:02:b3:9a:af:6d brd ff:ff:ff:ff:ff:ff
    inet6 ::ffff:192.168.13.236/120 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::202:b3ff:fe9a:af6d/64 scope link 
       valid_lft forever preferred_lft forever
[mpenning@hotcoffee ~]$

Answer 1

IPv4-mapped IPv6 addresses are not supposed to be assigned to IPv6 interfaces or for IPv6 native communication. Not on current Linux at least. Add normal IPv4 addresses using ip addr add, without the -6 flag and in normal IPv4 notation.

sudo ip addr add 192.168.13.236/24 dev eth3

And also, again, do not use ifconfig. It is old, deprecated, broken and superseded by iproute2. It will not display IPv6 addresses correctly, and will not display multiple IPv4 addresses on the same interface without aliases.

---

I'll clarify the discussion in the comments below here, since it is too big to post as another comment.

It doesn't make sense to add IPv4 addresses to the IPv6 stack, even if by converting them to IPv4-mapped IPv6 addresses. The IPv6 stack deals with IPv6 addresses and transmit IPv6 packets; the IPv4 stack deals with IPv4 addresses and transmit IPv4 packets.

Adding the address to the interface and pinging it may work probably because there is some sanity check missing in the kernel code that adds addresses to interfaces.

IPv4-mapped IPv6 addresses exist so that you can use IPv6 sockets (important note: that is application-level) to communicate to IPv4 hosts. You do not need to add a IPv4-mapped IPv6 address to your interfaces in order to communicate to them using IPv6. Try it:

ssh ::ffff:127.0.0.1

It will work transparently even though ::ffff:127.0.0.1 (IPv6) is not registered in the IPv6 stack for the loopback interface (lo). It works because 127.0.0.1/8 (IPv4) is. The system actually uses IPv4 packets even though you provided an IPv6 address. You may check this with wireshark or tcpdump. This is also valid when you receive an IPv4 packet or connection using an IPv6 socket bound/listening to the IPv6 wildcard address.

Note that ICMP and ping works differently because the API for ICMP sockets is completely different between IPv4 and IPv6. ping6 actually creates a raw ICMPv6 packet with the address given, which doesn't make sense in the wire. IMO this may be safely considered a bug, both ping6 and the kernel should fail earlier before injecting IPv6 packets with IPv4 addresses into the wire, or allowing such addresses to exist in the IPv6 stack.