Blog Cisco France – IPv6

J’ai testé pour vous : Stateful NAT64 avec DNS64

Mon post qui décrivait mes tests NAT64 ayant suscité beaucoup d’intérêt j’ai poursuivi les tests en ajoutant un DNS64 annoncé en DHCPv6. J’ai ensuite ajouté une borne wifi et me voilà eu bureau dans un environnement 100% IPv6!

Objectif du lab:

Mettre en oeuvre un environnement NAT64 stateful/ DNS64 et DHCPv6 complet et montrer comment il est possible très simplement de créer des ilots v6-only qui continuent d’avoir acès aux ressources sur l’internet IPv4.

Topologie:

La topologie du lab est la même que celle de mon test NAT64 précédent avec simplement l’ajout d’un serveur DNS64 et l’annonce de celui-ci via DHCPv6:

  • Le préfixe IPv6 complet du réseau du lab est 2001:db8:cafe::/48
  • Le préfixe IPv6 du lien 100% IPv6 est 2001:db8:cafe:100::/64. Les hosts s’auto-configurent via le mécanisme SLAAC.
  • Le préfixe spécifique IPv6 (NSP – Network Specific Prefix) associé à NAT64 stateful est 2001:db8:cafe:2::/96. Une adresse IPv4 A.B.C.D est convertie en 2001:db8:cafe:2::A.B.C.D
  • Le pool d’adresses IPv4 sur lesquelles sont “NATées” les adresses IPv6 ne compte qu’une seule adresse dans ce lab: 10.151.200.1
  • Un serveur DNS64 qui a pour adresse: 2001:db8:cafe:200:20c:29ff:fe08:6b90

 

Plateforme:

 

  • NAT64: Routeur ASR1004
  • DNS64: Serveur UCS

 

Software:

 

  • NAT64: IOS-XE 3.4.0S – advanced IP services (asr1000rp1-advipservicesk9.03.04.00.S.151-3.S.bin)
  • DNS64: BIND 9.8.1 sous Ubuntu 4.4.1 (pas très récent)

 

Détails des tests et résultats:

 

1. Configuration de la plateforme de test

 

1.1. Configuration de Stateful NAT64

 

La configuration est celle réalisée lors du test initial NAT64.

 

1.2. Configuration du DNS64

 

La configuration est extrêmement simple. Après avoir installé BIND 9.8.1, il m’a suffit de:
  • Configurer le serveur pour écouter en IPv6
  • Configurer le préfixe IPv6 associé à NAT64 (sur lesquelles les adresses IPv4 sont automatiquement traduite)
  • Configurer un forwarder (10.30.30.30 dans notre cas). Dans le cas le plus classique, on peut imaginer qu’une entreprise ne souhaitera pas initialement faire des modifications sur ses serveurs DNS pour déployer NAT64. Il est très simple de configurer le serveur DNS64 en mode proxy: il se contentera de relayer les requêtes sur le serveur DNS officiel puis de traduire les résultats.
  • Cas particulier: dans le lab qui a servi à faire les tests il n’y a pas d’accès internet IPv6. Il faut donc absolument éviter que le DNS64 retourne une adresse IPv6 globale dans le cas où le host recherché existe dans l’internet IPv6! Tout doit être natté64! Cela est fait via la ligne “exclude { ::/0; };” ci-dessous.
options {
  listen-on-v6 { any; };
  forwarders { 10.30.30.30; };
  dns64 2001:db8:cafe:2::/96 {
    exclude { ::/0; };
  };
  allow-query { any; };
  recursion yes;
};

 

1.3. Configuration de DHCPv6

 

Rien de plus simple. Sur l’interface Gi0/0/2 sur laquelle les hosts sont présents:

interface GigabitEthernet0/0/2
 description LAN V6 ONLY (NAT64)
 no ip address
 negotiation auto
 ipv6 address 2001:DB8:CAFE:100::1/64
 ipv6 dhcp server V6ONLY
 nat64 enable

 

Et en global, il suffit de définir le profil V6ONLY:

 

ipv6 dhcp pool V6ONLY
 dns-server 2001:DB8:CAFE:200:20C:29FF:FE08:6B90
 domain-name test.com

 

2. Tests et résultats

 

2.1. Validation du fonctionnement de DNS64

 

On peut faire un test simple en demandant les enregistrements A et AAAA pour www.test.com (qui n’est pas encore nativement accessible en IPv6, cad qui n’a pas d’adresse IPv6 dans le DNS).

root@dns64:~$ dig +short @127.0.0.1 -t A www.test.com
50.23.225.49
root@dns64:~$ dig +short @127.0.0.1 -t AAAA www.test.com
2001:db8:cafe:2::3217:e131

On observe que l’adresse 50.23.225.49 est bien embarquée dans l’adresse 2001:db8:cafe:2::3217:e131.

 

Je teste ensuite le comportement du DNS64 pour un host qui existerait dans l’internet IPv6 (www.renater.fr dans l’exemple ci-dessous)

root@dns64:~$ dig +short @10.30.30.30 -t AAAA www.renater.fr
2001:660:3001:4002::10
root@dns64:~$ dig +short @127.0.0.1 -t AAAA www.renater.fr
2001:db8:cafe:2::c131:9f0a

On observe que malgré la présence d’un enregistrement AAAA retourné par le forwarder du DN64 10.30.30.30, c’est bien l’adresse NAT64 qui est retournée grâce à la configuration “exclude { ::/0; }” de bind. Bien sûr dans l’hypothèse où un accès IPv6 existe, il faut supprimer cette exclusion pour privilégier l’accès IPv6 natif à celui NATté.

 

2.2. Validation de DHCPv6

 

Malheureusement DHCPv6 n’est pas supporté sur MAC OS! Aussi j’ai du configurer statiquement l’adresse IPv6 du serveur et supprimer toutes les configurations IPv4. Je ne manquerai pas de revenir sur DHCPv6 dans un prochain post.

2.3. Fonctionnement de l’ensemble

 

Que dire si ce n’est que tout fonctionne comme prévu sans constater de dégradation de performance? Après seulement quelques minutes de browsing la table de translation nat64 se remplit:

ASR1#sh nat64 translations 

Proto  Original IPv4         Translated IPv4
       Translated IPv6       Original IPv6 
----------------------------------------------------------------------------

tcp    144.254.231.90:993    [2001:db8:cafe:2::90fe:e75a]:993                
       10.151.20.1:1174      [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60213    
tcp    72.163.4.70:443       [2001:db8:cafe:2::48a3:446]:443                 
       10.151.20.1:1043      [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60052    
tcp    74.207.254.18:80      [2001:db8:cafe:2::4acf:fe12]:80                 
       10.151.20.1:1148      [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60161    
tcp    72.9.238.226:80       [2001:db8:cafe:2::4809:eee2]:80                 
       10.151.20.1:1166      [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60190    
tcp    74.125.39.103:443     [2001:db8:cafe:2::4a7d:2767]:443                
       10.151.20.1:1172      [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60209    
tcp    74.125.39.147:80      [2001:db8:cafe:2::4a7d:2793]:80                 
       10.151.20.1:1134      [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60140    
tcp    74.125.39.147:80      [2001:db8:cafe:2::4a7d:2793]:80                 
       10.151.20.1:1085      [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60115    
tcp    72.163.4.70:443       [2001:db8:cafe:2::48a3:446]:443                 
       10.151.20.1:1034      [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60037    
tcp    173.37.161.166:80     [2001:db8:cafe:2::ad25:a1a6]:80                 
       10.151.20.1:1063      [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60081    
tcp    69.171.242.53:80      [2001:db8:cafe:2::45ab:f235]:80                 
       10.151.20.1:1054      [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60062    
…
…

Total number of translations: 155

 

Un peu de lecture:

 

Stephane Bortzmeyer a réalisé 2 pages excellentes sur Stateful NAT64 et DNS64 que je vous recommande.

Tags: , , , , ,

IPv6 maintenant supporté sur ACE30 !

La release pour ACE30 (module de load-balacing pour catalyst6500) et ACE4710 (coffret de load-balacing autonome) qui apporte le support d’IPv6 est sortie!

Résumé des fonctionnalités:

  • IPv6 and IPv4 Dual Stack support
  • IPv6 addressing: link-local, global unicast, and unique local addresses
  • Neighbor discovery (NS, NA, RS, RA), duplicate address detection (DAD) and ICMPv6.
  • Support for DHCPv6 Relay agent.
  • IPv6 ACL and object-group
  • IPv6 Probes
  • Nat support extended from IPv4-IPv4 to IPv6-IPv6, IPv6-IPv4, IPv4-IPv6, IPv4-IPv4
  • L7 LB support extended for IPv6 flows based on HTTP, HTTPS and DNS traffic flows.
  • IP sticky and Predictor hash address support extended for IPv6
  • IPv6 support for TCP/IP Normalization, fragmentation/reassembly, switch-mode, server-conn reuse, compression, switch-mode
  • IPv6 connections replication support and IPv6 host/interface tracking
  • Inspection support for IPv6: HTTP, ICMPv6 and DNSv6
  • DM Support for IPv6 and SSL OCSP
  • DM support for Homepage, guided setup and network monitoring enhancement
  • SSL Online Certificate Status Protocol (OCSP)
  • IPv6 support extended for CRL and OCSP

Releases notes : http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA5_1_x/release/note/ACE_mod_rn_A51x.html

Les fonctions IPv6 “de base” sont dispos sans cout supplémentaire, il y a cependant une licence à 5k$ pour la translation 6-to-4.

Multicast IPv6 inter-domaine

J’ai encore vu passer récemment la question sur un forum: “Y’a-t-il un équivalent de MSDP pour IPv6 ?”. Ayant pas mal travaillé sur le sujet (et tout ce qui touche au multicast IPv6 d’une manière générale) je vais donc essayer de faire une réponse détaillée sur ce blog pour la communauté francophone.

MSDP ne supporte pas IPv6 (ou l’inverse) et il n’est a priori pas question que cela change. Le RFC3618 qui décrit MSDP est toujours “experimental” et il ne semble pas prévu d’en changer le statut. Il est donc difficile d’imaginer dans ces conditions une adoption par la communauté IPv6. Je rappelle brièvement que cette problématique ne concerne que le multicast en mode ASM (Any-Source Multicast), dans lequel un récepteur s’abonne à un groupe et désire recevoir le trafic de toutes les sources qui envoient des données à ce groupe. Dans le mode SSM (Source-Specific Multicast), la question de l’inter-domaine ne se pose pas puisque le récepteur s’abonne à un groupe en spécifiant la source (ou les sources) d’intérêt: aucun protocole de type MSDP n’est donc nécessaire pour découvrir les sources et le modèle est grandement simplifié.

Embedded-RP

La question qui se pose est donc “comment faire de l’interdomaine multicast ASM en IPv6?”. La réponse est embedded-RP (RFC3956), disponible sur les routeurs CISCO depuis déjà quelques années. Le principe d’embedded-RP (ou RP embarqué) consiste à profiter de la grande taille d’une adresse IPv6 multicast pour y insérer l’adresse du point de rendez-vous (RP). Comme il n’est pas possible d’insérer l’adresse unicast du RP (128 bits) dans une adresse multicast IPv6 (128 bits également), cette méthode suppose que l’adresse du RP soit d’un format particulier: ce format est bien décrit dans le RFC aussi je ne vais pas le décrire dans le détail ici. Sur les 64 derniers bits de l’adresse du RP, tous doivent être positionnés à 0 à l’exception des 4 derniers qui sont nommés Router Interface Identifier ou RIID.

La lecture d’une adresse multicast IPv6 de type embedded-RP permet automatiquement de déterminer le point de rendez-vous associé. Ce point de rendez-vous peut être n’importe où et la notion de domaine multicast n’existe plus (une source pouvant s’enregistrer sur le RP d’un réseau distant). Dans ces conditions un mécanisme comme MSDP n’est plus utile puisque toutes les sources et tous les récepteurs d’un groupe “utilisent” le même RP. Il faut donc voir embedded-RP comme un mécanisme permettant le group-to-RP mapping (c’est à dire une solution permettant de déterminer le RP correspondant à une adresse de groupe). Tous les routeurs doivent donc supporter embedded-RP pour que la solution fonctionne: le DR (Designated Router), le RP (point de rendez-vous) et tous les autres routeurs du réseau multicast IPv6. Les adresses multicast de type embedded-RP sont dans le préfixe par FF7x::/12. Le 7 correspond aux adresses multicast de type embedded-RP, le x correspond à la portée de l’adresse (E=global, 5=site…)

Si la solution technique existe, elle change le modèle connu en IPv4 dans lequel une source s’enregistre sur le RP de son domaine. Le modèle opérationnel change donc considérablement et il convient de le comprendre avant de le déployer, car les procédures de troubleshooting ne sont plus les mêmes: les PIM-registers traversant les domaines.

Comment déployer embedded-RP ?

Le mécanisme est automatiquement activé lors de l’activation du multicast IPv6:

ipv6 multicast-routing

Il est cependant possible de désactiver embedded-RP:

no ipv6 pim rp embedded

Pour configurer un point de rendez-vous de type embedded-RP il suffit d’utiliser les commandes habituelles de configuration de RP. La seule différence est que l’adresse du RP et les adresses de groupe configurées correspondent au mapping “embedded-RP” décrit dans le RFC3956. La configuration ne doit être faite que sur le RP:

ipv6 pim rp-address 2001:db8:cafe:f00d::1 EMBEDDED-RP-GROUP
ipv6 access-list EMBEDDED-RP-GROUP
 permit ipv6 any FF7E:140:2001:db8:cafe:f00d::/96

Et maintenant ? Comment utiliser le service ?

Embedded-RP impose d’utiliser des adresses IPv6 multicast qui “marchent”, c’est-à-dire dérivées d’un RP existant configuré. Ces adresses ne peuvent pas se deviner aussi à mon avis le mécanisme global ne sera complet qu’avec un mécanisme permettant d’allouer des adresses multicast IPv6. J’avais il y a déjà quelque temps proposé des mécanismes:

  • Basés sur DHCPv6: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01
  • Basés sur SLAAC: draft-jdurand-ipv6-multicast-ra-00.txt
  • Imposant que tous les DR soient des RP: draft-jdurand-all-drs-are-rps-00

Ces propositions n’ont pas avancé à l’époque, pousser SSM en avant étant selon la communauté la meilleure façon d’avancer de façon pragmatique.

J’ai testé pour vous : Stateful NAT64

A l’instar de ce que j’essaye de faire sur le blog “réseaux” http://reseauxblog.cisco.fr je vais tâcher de publier régulièrement des déploiements simples réalisés en lab, pour vous aider éventuellement à mettre le pied à l’étrier ou vous donner des exemples de déploiements. Passée peut-être inaperçue au milieu des vacances d’été, la sortie de stateful NAT64 dans la version d’IOS-XE 3.4S (ASR1000) est pourtant une avancée majeure qui permettra de faciliter la transitions progressive vers IPv6. Je pense par exemple aux scénarios suivants:

  • Nécessité de rendre accessible à l’internet IPv6 des serveurs purement IPv4 (présence Internet)
  • Possibilité de déployer des portions de réseau 100% IPv6 tout en laissant l’accès à l’internet IPv4. Ainsi le NAT44 actuel est remplacé par du NAT64 pour les services non IPv6 (complexité inchangée pour l’administrateur), et les services IPv6 bénéficient d’une connectivité native (à condition bien sûr d’avoir souscrit des services IPv6 auprès de son opérateur).
  • Possibilité pour une entreprise 100% IPv4 d’accéder à des services disponibles uniquement sur IPv6

Les exemples ne manquent pas et nous aurons l’occasion de revenir sur le sujet sur ce blog. Je vais ici surtout m’attarder sur le déploiement réalisé en lab.

 

Objectif du lab:

 

Montrer le fonctionnement de NAT64 stateful et la simplicité de déploiement sur IOS-XE. Le lab montre l’exemple d’un réseau 100% IPv6 qui doit accéder à des applications IPv4 (FTP et WEB). Nous pourrons voir que l’implémentation de stateful NAT64 va au-delà de la simple conversion des en-têtes IP puisque le protocole FTP nécessite également des modifications dans le contenu du paquet. Dans ce lab je n’ai pas déployé DNS64, aussi les tests seront faits en convertissant “à la main” les adresses IPv4 des services vers le préfixe spécifique IPv6 utilisé par NAT64 (NSP – Network Specific Prefix). Le lecteur peut lire ce whitepaper qui rappelle didactiquement le fonctionnement de NAT64.

 

Topologie:

 

La topologie du lab est représenté dans la figure ci-dessous:

  • Le préfixe IPv6 complet du réseau du lab est 2001:db8:cafe::/48
  • Le préfixe IPv6 du lien 100% IPv6 est 2001:db8:cafe:100::/64. Les hosts s’auto-configurent via le mécanisme SLAAC
  • Le préfixe spécifique IPv6 (NSP – Network Specific Prefix) associé à NAT64 stateful est 2001:db8:cafe:2::/96. Une adresse IPv4 A.B.C.D est convertie en 2001:db8:cafe:2::A.B.C.D
  • Le pool d’adresses IPv4 sur lesquelles sont “NATées” les adresses IPv6 ne compte qu’une seule adresse dans ce lab: 10.151.200.1

 

Plateforme:

 

  • ASR1004

 

Software:

 

  • IOS-XE 3.4.0S – advanced IP services (asr1000rp1-advipservicesk9.03.04.00.S.151-3.S.bin)

 

Détails des tests et résultats:

 

1. Configuration de Stateful NAT64

 

La configuration est très simple: il suffit d’indiquer globalement les préfixes IPv6 pour lesquels NAT64 est activé, le pool d’adresses IPv4, puis d’activer la translation sur les interfaces concernées.

 

  • Configuration du préfixe IPv6 spécifique utilisé pour la conversion des adresses IPv4 externes dans des adresses IPv6 qui seront utilisées dans le réseau interne (conversion faite normalement par NAT64). Un préfixe de taille 96 est utilisé (les 32 bits restants “embarquent” l’adresse IPv4).

 

nat64 prefix stateful 2001:DB8:CAFE:2::/96

 

  • Configuration du pool d’adresses IPv4 utilisé pour la translation. Dans ce cas le pool ne contient qu’une adresse: 10.151.20.1

 

nat64 v4 pool MYPOOL 10.151.20.1 10.151.20.1

 

  • Configuration de la translation proprement dite (entre les adresses contenues dans l’ACL IPv6 MYLIST et le pool défini précédemment)

 

nat64 v6v4 list MYLIST pool MYPOOL overload
ipv6 access-list MYLIST
 permit ipv6 2001:DB8:CAFE::/48 any

 

  • Activation de NAT64 sur les interfaces Gi0/0/2 (purement IPv6) et Gi0/0/3 (purement IPv4).

 

interface GigabitEthernet0/0/2
 description LAN V6 ONLY
 no ip address
 negotiation auto
 ipv6 address 2001:DB8:CAFE:100::1/64
 nat64 enable
!
interface GigabitEthernet0/0/3
 description TO V4 ONLY INTERNET
 ip address 10.153.12.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
 negotiation auto
 nat64 enable

 

A ce stade la configuration de NAT64 est terminée! Automatiquement la conversion applicative (ALG – Application Level Gateway) pour le protocole FTP est activée. Il est possible de la désactiver simplement via la commande “no nat64 service ftp”

 

2. Tests

 

Tous les tests sont faits entre les hosts du lien IPv6 (2001:db8:cafe:100:ca2a:14ff:fe2d:a5fd et 2001:db8:cafe:100:ca2a:14ff:fe2d:a5fd) et le serveur WEB / FTP IPv4 10.100.100.100. L’adresse IPv4 10.100.100.100 est manuellement convertie dans le préfixe spécifique IPv6 NSP vers l’adresse 2001:db8:cafe:2::0A64:6464 (0A64:6464 est la conversion de 10.100.100.100 en hexadecimal)

 

2.1. Accès serveur WEB depuis Host-2

 

Un telnet sur le port 80 de l’adresse convertie du serveur web IPv4 est fait sur Host-2:

 

Host-2$ telnet 2001:db8:cafe:2::0A64:6464 80
Trying 2001:db8:cafe:2::a64:6464...
Connected to 2001:db8:cafe:2::0A64:6464.

Escape character is '^]'.

 

La connexion est réalisée sur le serveur web 10.100.100.100. On peut voir sur le routeur la table de translation ci-dessous:

 

ASR1000#sh nat64 translations

Proto  Original IPv4         Translated IPv4
       Translated IPv6       Original IPv6
----------------------------------------------------------------------------

tcp    10.100.100.100:80     [2001:db8:cafe:2::a64:6464]:80
       10.151.20.1:1024      [2001:db8:cafe:100:ca2a:14ff:fe2d:a5fd]:58568

Total number of translations: 1

 

On observe la table de conversion avec les 2 couples d’adresses/ports IPv4 et IPv6:
– Adresse/port IPv4 du serveur (10.100.100.100:80)
– Adresse/port IPv6 convertie correspondant au serveur web ([2001:db8:cafe:2::a64:6464]:80)
– Adresse/port IPv4 du pool utilisée pour le NAT, conversion de l’adresse IPv6 de Host-2 (10.151.20.1:1024)
– Adresse/port IPv6 de Host-2 ([2001:db8:cafe:100:ca2a:14ff:fe2d:a5fd]:58568)

 

2.2. Ping serveur depuis Host-2

 

Host-2$ ping6 2001:db8:cafe:2::0A64:6464
PING6(56=40+8+8 bytes) 2001:db8:cafe:100:ca2a:14ff:fe2d:a5fd
 --> 2001:db8:cafe:2::a64:6464
16 bytes from 2001:db8:cafe:2::a64:6464, icmp_seq=0 hlim=125 time=0.858 ms
16 bytes from 2001:db8:cafe:2::a64:6464, icmp_seq=1 hlim=125 time=0.683 ms
16 bytes from 2001:db8:cafe:2::a64:6464, icmp_seq=2 hlim=125 time=0.642 ms
16 bytes from 2001:db8:cafe:2::a64:6464, icmp_seq=3 hlim=125 time=0.676 ms
^C
--- 2001:db8:cafe:2::0A64:6464 ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.642/0.715/0.858/0.084 ms

 

Le serveur répond bien aux pings. La table de translation contient les informations suivantes:

 

ASR1000#sh nat64 translations

Proto  Original IPv4         Translated IPv4
       Translated IPv6       Original IPv6
----------------------------------------------------------------------------

icmp   10.100.100.100:1      [2001:db8:cafe:2::a64:6464]:15322
       10.151.20.1:1         [2001:db8:cafe:100:ca2a:14ff:fe2d:a5fd]:15322

Total number of translations: 1

 

2.3. Accès au serveur FTP depuis Host-2

 

Host-2$ ftp 2001:db8:cafe:2::0A64:6464
Connected to 2001:db8:cafe:2::0A64:6464.
Name (2001:db8:cafe:2::0A64:6464): XXX
331 Password required for XXX
Password:
230 Logged on
Remote system type is UNIX.
ftp> bye
221 Goodbye
ASR1000#sh nat64 translations

Proto  Original IPv4         Translated IPv4
       Translated IPv6       Original IPv6
----------------------------------------------------------------------------

tcp    10.100.100.100:21     [2001:db8:cafe:2::a64:6464]:21
       10.151.20.1:1025      [2001:db8:cafe:100:ca2a:14ff:fe2d:a5fd]:58559

Total number of translations: 1

 

2.4. Accès simultané au serveur FTP depuis Host-1 et Host-2

 

Les deux hosts accèdent simultanément au serveur sans difficultés. La table de conversion NAT64 intègre les 2 entrées pour les 2 hosts. On observe bien que les 2 hosts IPv6 sont “NATés” sur la même adresse IPv4 (avec bien évidemment des ports TCP distincts)

 

ASR1000#sh nat64 translations

Proto  Original IPv4         Translated IPv4
       Translated IPv6       Original IPv6
----------------------------------------------------------------------------

tcp    10.100.100.100:21     [2001:db8:cafe:2::a64:6464]:21
       10.151.20.1:1024      [2001:db8:cafe:100:ca2a:14ff:fe2d:a5fd]:58912
tcp    10.100.100.100:21     [2001:db8:cafe:2::a64:6464]:21
       10.151.20.1:1025      [2001:db8:cafe:100:4410:d7d2:ed19:3f9d]:1025

Total number of translations: 2

 

2.5. Pings simultanés du serveur depuis Host-1 et Host-2

 

Des pings sont réalisés simultanément depuis Host-1 et Host-2, les 2 hosts reçoivent des réponses du serveur. On voit la conséquence dans la table de translation NAT64 avec les 2 entrées ICMP.

 

ASR1000#sh nat64 translations

Proto  Original IPv4         Translated IPv4
       Translated IPv6       Original IPv6
----------------------------------------------------------------------------

icmp   10.100.100.100:1      [2001:db8:cafe:2::a64:6464]:16849
       10.151.20.1:1         [2001:db8:cafe:100:ca2a:14ff:fe2d:a5fd]:16849
icmp   10.100.100.100:2      [2001:db8:cafe:2::a64:6464]:0
       10.151.20.1:2         [2001:db8:cafe:100:4410:d7d2:ed19:3f9d]:0

Total number of translations: 2

Tags: , , ,

IPv6, Eric Besson et le futur réseau inter-ministériel

Un article sur la position d’Eric Besson vis à vis d’IPv6:

http://www.itespresso.fr/ipv6-eric-besson-souhaite-que-l-etat-donne-l-exemple-45540.html

Le 9 Juin, Eric Besson avait déjà publié un communiqué de presse parlant d’une accélération de la migration IPv6 en France, ainsi que sa mise en oeuvre dans le cadre du nouveau réseau inter-ministériel:

http://pubminefi.diffusion.finances.gouv.fr/pub/document/18/10875.pdf

Hier s’est tenue une réunion sur le sujet à Bercy. Etaient présents les opérateurs, des membres du G6, de l’AFNIC, la DISIC (Direction interministérielle des systèmes d’information et de  communication de l’État), deux personnes de Cisco ainsi que d’autres personnes …

Cisco IOS Advantage – IPv6 Deployment and Operation Experiences

Le prochain IOS Webinar est prévu le 7 septembre et portera sur le déploiement IPv6.

Duration: 2 hours
Date: Wednesday, September 7, 2011
Time: 8 AM Pacific – Register now

 

Cisco IOS Advantage Webinar – NAT64

Les Cisco IOS Advantage Seminars sont des rendez-vous régulier permettant d’avoir une présentation par les meilleurs spécialistes Cisco sur des technologies embarquées dans IOS.

Le dernier Webinar portait sur NAT64.

Il est possible de le voir en allant sur le recording Webex ici :

 

Synthèse des fonctionnalités IPv6 sur les équipements CISCO

Si vous cherchez une synthèse des fonctionnalités IPv6 sur IOS et IOS-XE, ces deux liens devraient vous aider à avoir une bonne vue d’ensemble:

Rappel: utilisez en complément le feature navigator si vous recherchez des infos précises sur une fonctionnalité particulière:

Facebook Reports on IPv6 Day

Facebook Reports on IPv6 Day

Small take from the story…

Facebook:
We saw over 1 million users reach us over IPv6.

We’re pleased that we did not see any increase in the number of users seeking help from our Help Center.

Based on the encouraging results, we’ve decided to leave our Developer site dual-stacked, supporting both IPv4 and IPv6. And we will continue to adapt our entire code base and tools to support IPv6.

SFR France Deploys Cisco Carrier Grade IPv6 Solution

Encore une bonne nouvelle après cette belle journée IPv6.

SFR après Free annonce le déploiement d’IPv6 sur son réseau à l’aide de la solution Cisco Carrier Grade IPv6 sur base de Cisco ASR 1000.

Cisco News Room