Incapacidade de usar o IPv6 mapeado para IPv4 no debian squeeze

Question

Eu tenho uma squeeze que estou testando o ipv6 em ... eth3 é a interface ... se eu configurar um endereço ipv6 'normal' ( ::101:c0a8:3132/120 ), vejo os resultados esperados em 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

Mas se eu configurar um endereço IPv6 mapeado para IPv4 , não vejo parte do endereço ...

[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

Este endereço não deve ser exibido como ::ffff:192.168.13.236/120 em vez de 192.168.13.236/120 ?

Eu também estou tendo um problema no ping quando o endereço IPv6 mapeado do IPv6 é atribuído, então agora eu me pergunto se isso está relacionado à exibição inesperada no ifconfig, ou algo errado no outro lado.

EDITAR:

Usando 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

Os endereços IPv6 mapeados para IPv4 não devem ser atribuídos a interfaces IPv6 ou a comunicações nativas IPv6. Não no Linux atual, pelo menos. Adicione endereços IPv4 normais usando ip addr add , sem o sinalizador -6 e na notação IPv4 normal.

sudo ip addr add 192.168.13.236/24 dev eth3

E também, novamente, não use ifconfig . É antigo , reprovado , quebrado e substituído por proute2 . Ele não exibirá endereços IPv6 corretamente e não exibirá vários endereços IPv4 na mesma interface sem aliases.

Vou esclarecer a discussão nos comentários abaixo, já que é grande demais para postar como outro comentário.

Não faz sentido adicionar endereços IPv4 à pilha IPv6, mesmo convertendo-os em endereços IPv6 mapeados para IPv4. A pilha IPv6 lida com endereços IPv6 e transmite pacotes IPv6; a pilha IPv4 lida com endereços IPv4 e transmite pacotes IPv4.

Adicionando o endereço à interface e o ping pode funcionar provavelmente porque existe alguma verificação de integridade faltando no código do kernel que adiciona endereços às interfaces.

Existem endereços IPv6 mapeados para IPv4 para que você possa usar soquetes IPv6 (nota importante: nível de aplicativo) para se comunicar com hosts IPv4. Você não precisa adicionar um endereço IPv6 mapeado para IPv4 às suas interfaces para se comunicar com elas usando o IPv6. Experimente:

ssh ::ffff:127.0.0.1

Ele funcionará de forma transparente mesmo que :: ffff: 127.0.0.1 (IPv6) não esteja registrado na pilha IPv6 da interface de loopback ( lo ). Funciona porque 127.0.0.1/8 (IPv4) é. O sistema realmente usa pacotes IPv4, mesmo que você tenha fornecido um endereço IPv6. Você pode verificar isso com o wireshark ou o tcpdump. Isso também é válido quando você recebe um pacote ou conexão IPv4 usando um soquete IPv6 ligado / escutando o endereço curinga do IPv6.

Observe que o ICMP e o ping funcionam de maneira diferente porque a API para sockets ICMP é completamente diferente entre o IPv4 e o IPv6. ping6 na verdade cria um pacote ICMPv6 com o endereço fornecido, o que não faz sentido no fio. IMO, isto pode ser seguramente considerado um bug, tanto ping6 quanto o kernel devem falhar antes de injetar pacotes IPv6 com endereços IPv4, ou permitir que tais endereços existam na pilha IPv6.