Good bye ARP, welcome ICMPv6

Today I was working on an IPv6 lab. I wanted discover the relation between an address MAC and an IP address. So, on the windows machine I execute the command 'arp -a'. It's a bad reflex, why ? ARP no longer exists in IPv6. The equivalent is now realized with ICMPv6. So to discover the correlation between MAC and IP address we have to use these commands:

• On a windows laptop:

C:\Users\Administrator>netsh interface ipv6 show neighbors 14

Interface 14: LAB

Internet Address                               Physical Address    Type
--------------------------------------------           -----------------             -----------
fe80::2                                             00-14-1c-c9-d9-a8    Stale (Router)
fe80::214:1cff:fec9:d9a8                     00-14-1c-c9-d9-a8    Stale (Router)
ff02::2                                              33-33-00-00-00-02     Permanent
ff02::5                                              33-33-00-00-00-05     Permanent
ff02::c                                              33-33-00-00-00-0c     Permanent
ff02::16                                            33-33-00-00-00-16     Permanent
ff02::1:2                                           33-33-00-01-00-02     Permanent
ff02::1:3                                           33-33-00-01-00-03     Permanent
ff02::1:ff00:2                                     33-33-ff-00-00-02      Permanent
ff02::1:ff00:d                                     33-33-ff-00-00-0d      Permanent
ff02::1:ff00:f                                      33-33-ff-00-00-0f       Permanent
ff02::1:ff08:c77                                 33-33-ff-08-0c-77       Permanent
ff02::1:ffae:564d                               33-33-ff-ae-56-4d       Permanent
ff02::1:ffc9:d9a8                               33-33-ff-c9-d9-a8       Permanent  
  

• On a Linux laptop (has to be validated):

ip -f inet6 neigh show

• On a Cisco router:

R2#show ipv6 neighbors
IPv6 Address                                         Age Link-layer Addr    State      Interface
FE80::4491:69A9:39F3:7344                   5     000c.2928.4c53  STALE    Fa0/0
2001:DB9:1:1:DD52:657C:D340:F2FF      19   000c.2980.fc6c   STALE    Fa0/0
2001:DB9:1:1:B140:2298:3E92:A99B       6     000c.2928.4c53  STALE    Fa0/0
FE80::1                                                 4     0016.479a.f630   STALE    Fa0/0
FE80::20C:29FF:FE80:FC6C                  19    000c.2980.fc6c   STALE    Fa0/0
2001:DB9:1:1::1                                     22    0016.479a.f630  STALE    Fa0/0

Used IPv6 stateful Autoconfiguration

I would like add some details to my post vista and DHCPv6 (in french). I would like detailed which mechanisms is used to choose between stateless and stateful configuration. The DHCPv6 client used 2 bits in the RA  (Routers Advertisements send by the router) in order to know if DHCPv6 server is available:

• O bit: with this bit, a IPv6 host can use DHCPv6 to collect some parameters like DNS server address. However DHCPv6 server doesn't provide the client's IP address. Host use stateless configuration.
• M bit: with this bit, a IPv6 host can use DHCPv6 to collect a IPv6 address and others parameters from the server.
• Without these bits set, the IPv6 host will use stateless autoconfiguration.

The command managed-config-flag  which is used in the router doesn't force hosts to use DHCPv6. It's just a suggestion.

Protect against unwanted Router Advertisements (RA)

RA is used by auto-configuration. What is it auto-configuration ? It's a solution who allows devices to choose their own address.
How it works ?

Autoconfiguration is a two-step process:

- Host has to obtain prefix information to configure its address. To do this, it sends a Router Solicitation (RS). It's a multicast frame (ICMPv6 RS) for each router.
- Router advertisement (RA) is sent back by the router. These RAs are also sent periodically by the router. In our case, it's an instantaneous response.

It's a helpful solution for administrator but it's also a good way for hacker to shunt data flows. A hacker can send a wrong RA to a device. In this case, there are 2 issues, denial of service or man in the middle attack. If the hacker sends his own address (gateway information in the RA) all the flows can pass through him. Another error can occur with a misconfigured device, the host should obtain a wrong prefix. To protect against this kind of attack you can use this simple configuration (Port ACL) to stop untrusted RA. The access-list stop RA on all the untrusted interface. Just keep free interface where the router is plugged:

ipv6 access-list filter_RA
 remark Block Rogue RA
 deny icmp any any router-advertisement
 permit any any
!
interface gigabitethernet 1/0/10
 ipv6 traffic-filter filter_RA in

On the Catalyst 6500 and 4500 it's possible to use a macro to configure this kind of PACL:

interface gigabitethernet 1/0/10

 ipv6 nd raguard 

It's also possible to filter DHCPv6 with a PACL and just authorize the interface of the server to send response:

ipv6 access-list filter_DHCP
 remark Block traffic from DHCP to client
 deny udp any eq 547 any eq 546
 permit any any
!
interface gigabitethernet 1/0/10
 ipv6 traffic-filter filter_DHCP in

NAT64 et DNS64

La normalisation par l'IETF du mécanisme de translation d'adresse IPv6 vers IPv4 est effective (RFC6144). Elle repose sur le NAT64 (RFC6146 ) et le DN64 (RFC6147). Je pense que cette dernière sera une composante importante dans les mécanismes de coexistence entre IPv4 et IPv6.

Le but de ce mécanisme est de préciser le fonctionnement général d'une communication entre une machine en IPv6 et une machine en IPv4. Il est à noter que ce type de protocole (NAT64) repose sur une communication client/serveur.

L'intérêt de cette RFC est de permettre à une entreprise ou un ISP dont seule une plage d'adresse IPv6 leur sera affectée de continuer à communiquer avec le reste du monde (en IPv4).

Le déploiement de ce mécanisme nécessite 2 équipements:

• Le routeur qui réalisera le NAT64
• Le DNS64 qui permet de traduire un enregistrement A en un enregistrement AAAA

Le schéma ci-dessous détail la mise en œuvre:

1. Le client réalise une requête DNS vers le DNS64
2. Si le domaine ne possède pas d'enregistrement AAAA (retour message erreur) le serveur DNS64 effectue une requête A
3. Le serveur IPv6 génère une adresse IPv6 avec le préfixe 64:FF9B::/64 et renvoie cette dernière au client
4. Le client reçoit une adresse AAAA
5. Le client initie une communication avec le serveur au travers du routeur NAT64
6. Le routeur NAT64 créé une session via l'association adresse IP + port

Les implémentations existantes de NAT64:

- Ecdysis, opensource

- Cisco dans une version IOS XE

Les implémentations existantes de DNS64:

- Bind 9.8.0

IPv6: un point sur les Opérateurs français et les accès aux particuliers

Ce post a pour vocation de lister l'avancement du déploiement d'IPv6 chez les principaux opérateurs français. Je n'ai étudié que les offres réservées aux particuliers.

SFR:
Ils annoncent la possibilité de passer en IPv6 sur les neufBox d'ici cet été:
http://www.sfr.com/les-mondes-numeriques/les-nouvelles-technologies/ipv6-un-nouveau-protocole

Orange:
La livebox n'est pas aujourd'hui compatible avec IPv6. L'opérateur a annoncé sur twitter que cette dernière serait compatible dans ça nouvelle génération disponible à l'horizon de l'été 2012.
Si cela est confirmé, l'impact sera important puisque seules les nouvelles livebox n'auront cette fonctionnalité. Le changement de parc est donc considérable.
https://twitter.com/#!/presseorange/status/25907079453614080


Free:
Ils ont déployé la technologie 6rd qui permet d'offrir un accès IPv6 aux clients dégroupés et ceux depuis 2007.
http://www.iliad.fr/presse/2007/CP_IPv6_121207.pdf
Aujourd'hui aucune information circule sur les accès non dégroupés.


Bouygues Telecom:
La seule information que j'ai trouvé à leur sujet est que la nouvelle Bbox fibre supporte IPv6 en dual stack après upgrade FW .

Vista et DHCPv6

Vista implante le protocole DHCPv6 or après avoir implanté un serveur DHCPv6, je n'arrivais pas à obtenir une adresse via le DHCP.

Après plusieurs essais, je me suis rendu compte qu'il fallait modifier un champ des paquets Router advertisement : Avant modification du RA distribué par le routeur

0000 33 33 00 00 00 01 00 19 06 2f e9 fc 86 dd 6e 00 33...... ./....n.
0010 00 00 00 40 3a ff fe 80 00 00 00 00 00 00 02 19 ...@:... ........
0020 06 ff fe 2f e9 fc ff 02 00 00 00 00 00 00 00 00 .../.... ........
0030 00 00 00 00 00 01 86 00 2e db 40 "20" 07 08 00 00 ........ ..@ ....
0040 00 00 00 00 0b b8 01 01 00 19 06 2f e9 fc 05 01 ........ .../....
0050 00 00 00 00 05 dc 03 04 40 e0 00 27 8d 00 00 09 ........ @..'....
0060 3a 80 00 00 00 00 20 00 12 34 45 67 89 ac 00 00 :..... . .4Eg....
0070 00 00 00 00 00 00 ......

Quand vista reçoit cet RA, il ne produit pas de DHCPv6 solicitation
Après la commande ipv6 nd managed-config-flag sur l'interface réseau d'un routeur cisco. Nouvel RA :
0000 33 33 00 00 00 01 00 19 06 2f e9 fc 86 dd 6e 00 33...... ./....n.
0010 00 00 00 40 3a ff fe 80 00 00 00 00 00 00 02 19 ...@:... ........
0020 06 ff fe 2f e9 fc ff 02 00 00 00 00 00 00 00 00 .../.... ........
0030 00 00 00 00 00 01 86 00 2e 5b 40 "a0" 07 08 00 00 ........ .[@.....
0040 00 00 00 00 0b b8 01 01 00 19 06 2f e9 fc 05 01 ........ .../....
0050 00 00 00 00 05 dc 03 04 40 e0 00 27 8d 00 00 09 ........ @..'....
0060 3a 80 00 00 00 00 20 00 12 34 45 67 89 ac 00 00 :..... . .4Eg....
0070 00 00 00 00 00 00
Maintenant Vista envoie un DHCPv6 solicitation et reçoit une adresse du serveur DHCP.