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
- ASR1004
- IOS-XE 3.4.0S – advanced IP services (asr1000rp1-advipservicesk9.03.04.00.S.151-3.S.bin)
- 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”
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)
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
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
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
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
Authors
1 commentaires