Happy admins ?

Dans son dernier article Jean-Marc Barozet a expliqué « Happy Eyeball », ou comment le choix se faisait entre IPv4 et IPv6. Si pour l’usager c’est parfait car cela garantit a priori que le choix se fera en fonction de la performance, cela introduit un côté non déterministe qui peut ne pas plaire à tous les admins… Voici un aperçu de ce que pourrait être un dialogue entre un usager qui se plaint d’un problème de performance à son admin:

USAGER  – Bonjour, je vous appelle pour un problème de performance vers http://www.monservicecloud.com.
ADMIN  – Très bien je regarde, il s’avère que ce service est disponible à la fois pour IPv4 et IPv6. Pourriez-vous me dire quelle version de l’Internet vous avez utilisé?
USAGER  – Euuhhhh
ADMIN  – En ce cas je ne peux rien faire, n’hésitez pas à regarder ce point avant de m’appeler la prochaine fois. Bonne journée!

Lire la suite

IPv6 via IPv4 Service Provider Networks – “6rd”

Déployer IPv6 dans un réseau opérateur de type résidentiel … comment faire ? Quels sont les obstacles ?

Si on regarde les difficultés potentielles pour mettre en place IPv6 chez un ISP, on arrivera rapidement sur la partie agrégation, autrement dit sur la partie entre la box résidentielle et le routeur d’agrégation. Toute cette partie du réseau sur laquelle on trouve les DSLAMs, les différentes méthodes d’authentification (de PPP à DHCP), les serveurs Radius .. bref tout un ensemble complexe de produits n’ayant pas toujours un support IPv6 ou alors nécessitant une refonte qui peut s’avérer profonde.

De l’autre coté, le besoin IPv6 est la, les opérateurs veulent déployer rapidement, et surtout pouvoir le faire de manière progressive.
Et puis on le sait bien, offrir IPv6 aux utilisateurs, c’est permettre au trafic IPv6 Internet de progresser, donc d’intéresser plus de monde, donc de générer plus d’intérêt de la part des fournisseurs d’applications.

Alors la solution appelée 6rd est vraiment prometteuse. On l’a vu avec Free, un déploiement très rapide, graduel, flexible, un trafic IPv6 qui monte alors même que tous les utilisateurs n’ont pas encore coché la case qui va bien pour disposer d’IPv6. Au passage Free s’est taillé une belle réputation d’innovateur dans le monde des ISP, geeks et autres membres de l’IETF avec par exemple des présentations qui ont marqué dans les sessions du RIPE :

http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/ipv6-free.pdf

ou Google qui cite Free dans toutes leurs présentations.

Imaginons que cette case IPv6 soit cochée par défaut pour tous les utilisateurs de Free … quel serait le trafic IPv6 en sortie du réseau de Free ? On a bien une idée ici …

Alors 6rd c’est quoi exactement …

Principe

C’est avant tout une méthode incrémentale de déploiement d’IPv6, à considérer comme une méthode de production, donc de qualité et non pas comme un service d’expérimentation en attendant mieux. L’idée est de ré-utiliser le réseau IPv4 de l’opérateur dans l’accès et l’agrégation, c’est à dire la ou la difficulté de déploiement d’IPv6 est la plus grande.
La Residential Gateway (RG, la box dans le jargon francais), monte un tunnel de type IPv6 over IPv4 a destination d’un routeur d’agrégation en périphérie du backbone.
Le routeur qui recoit cette trame IPv4 décapsule la trame IPv6 et la route ensuite nativement dans le réseau backbone.

6rd-1

Technologie

Et pour entrer un peu plus dans les détails “sordides”, on distingue 3 grandes parties dans 6rd :

  • Délégation de préfixe : la box construit son adresse IPv6 sur un principe assez similaire à celui de 6to4, hormis le fait que le préfixe utilisé est le préfixe de l’ISP et non pas 2002::/16, donc construit son préfixe en fonction de son adresse IPv4 coté interface WAN. Cette adresse IPv4 peut être globale ou privée de type RFC1918.
  • Encapsulation et mapping : les trames IPv6 sont encapsulées dans IPv4 entre la box et le routeur qui termine le tunnel, appelé Border Relay (BR) en suivant les principes de la RFC 4213. Cette encapsulation et ce mapping n’ont pas d’état (stateless) et ce point la est particulièrement important pour être capable de faire évoluer cette technologie sur des routeurs de coeur.
  • Border Router : Une adresse de type anycast permettra d’envoyer les trames IPv6 sur IPv4 de la box vers un des Border Relay. On peut utiliser des adresses anycast justement parce que ce mapping iPv6 sur IPv4 est sans état.

Préfixe IPv6 en 6rd

Imaginons que la box ait comme adresse IPv4 : 129.1.1.1
On peut alors construire son adresse IPv6 comme suit :

  • le préfixe 6rd du domaine de l’opérateur (ce préfixe est obtenu à partir d’une registry, le RIPE en Europe). Il est de taille variable, ca peut etre un sous-ensemble d’un préfixe plus large.
  • concaténé avec l’adresse IPv4 (donc 32 bits). On peut prendre l’adresse IPv4 complète ou simplement des bits de poids faibles si par exemple tout est numéroté en 10.0.0.0/8

Exemple 1 avec un préfixe 6rd de /28 et l’adresse IPv4 complète :

6rd-2

Exemple 2 avec un préfixe 6rd de /32 et en prenant les 3 octets de poids faibles de l’adresse IPv4, donc sans le “10.” :

6rd-3

Standardisation

Pour que cette solution soit un succès, il faut évidemment qu’elle soit normalisée afin que tous les fabricants de routeurs mais aussi (et surtout ?) de Residential Gateways implémentent cette technologie 6rd. Rien ne pourra se faire si les box n’ont pas la partie de code 6rd qui va bien.

Cette solution a été utilisée par Free sur la base de la proposition de Rémi Despres : http://tools.ietf.org/html/draft-despres-6rd-03

Aujourd’hui, 6rd est un draft IETF dans le standard track : http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd
Les deux auteurs sont des personnes de Cisco, dont Mark basé à Paris.

Pour plus d’information : http://www.cisco.com/go/cgv6

Cisco Carrier Grade IPv6 Solutions (CGv6)

Une annonce importante dans le cadre du déploiement IPv6 pour les opérateurs. On l’attendait, elle est dispo : Cisco Carrier-grade IPv6 Solutions, ou CGv6.

Pourquoi cette annonce

La fin de la disponibilité de nouvelles adresses IPv4 est une préoccupation réelle à l’échelle mondiale.
Selon les différentes sources et les différents registres, la fin annoncée de la distribution est prévue pour 2011.
Une étude détaillée se trouve sur : http://www.potaroo.net/tools/ipv4

Enfin les choses bougent du coté des différents opérateurs, aussi bien dans le domaine résidentiel que dans celui des services aux entreprises. L’idée est de fournir des solutions évolutives qui permettent de répondre à différents besoins : natter IPv4 vers IPv4 pour le trafic qui reste en IPv4, router nativement le trafic IPv6 et fournir des solutions de tunneling entre les box résidentielles et des routeurs d’aggrégation pour permettre de déployer tranquillement la partie accès DSL.

Ainsi, pour permettre d’intégrer IPv6 et de préparer la transition, Cisco annonce donc une stratégie à destination des opérateurs, stratégie basée sur 3 axes :

  • Préserver: les investissements et machines IPv4 en donnant les outils pour traiter le trafic IPv4
  • Préparer: à fournir des services IPv6
  • Développer: la croissance et l’innovation

Technologies et composants de CGv6

Plusieurs services sont offerts au travers de technologies de translation, tunneling et dual-stack.

Translation

  • IPv4 vers IPv4 (NAT44), appelé aussi Large Scale NAT (LSN)
  • Entre IPv6 et IPv4 (NAT46, NAT64), appelé aussi Address Family Translation (AFT)

Tunneling

  • IPv4-over-IPv6 (4over6), appelé aussi IPv6 Rapid Deployment (6rd)
  • IPv6-over-IPv4 (6over4), appelé aussi Dual-Stack Lite (DS-lite)

Ces services seront délivrés notamment au travers d’une carte pour CRS-1 appelée Carrier Grade Services Engine (CGSE), sur l’ASR 1000 mais aussi sur d’autres produits de la gamme Cisco.

Dans les méthodes de tunneling IPv6 over IPv4, une méthode apparait comme extrèmement intéressante pour les opérateurs : 6rd.
Au final, dans un déploiement IPv6, la partie du réseau opérateur la plus difficile à traiter est le réseau d’aggrégation DSL. La partie coeur est constitué de routeurs ayant nativement la possibilité de fonctionner en dual-stack, avec un traitement hardware.
6rd permet de déployer rapidement IPv6 en tunnelant le trafic depuis les box résidentielles vers des routeurs d’aggrégation pour ensuite le router nativement.

Cette solution a été utilisée par Free sur la base de la proposition de Rémi Despres : http://tools.ietf.org/html/draft-despres-6rd-03

et est aujourd’hui dans un draft IETF dans le standard track : http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd

Pour plus d’information : http://www.cisco.com/go/cgv6

Snow Leopard et IPv6

Bon ca y est Snow Leopard est sorti. En bon utilisateur fan de MacOSX, je me précipite dessus pour l’installer.
Qu’en est-il de la partie réseau et notamment d’IPv6 ?

Mac OS X 10.5, Leopard:
$ sysctl -a | grep kame_version
net.inet6.ip6.kame_version: 20010528/apple-darwin

Mac OS X 10.6, Snow Leopard:
$ sysctl -a | grep kame_version
net.inet6.ip6.kame_version: 20010528/apple-darwin

La stack KAME de … 2001 …. stable, pas de doute.

Mais pas le moindre changement ! Pas la plus petite différence .. donc pas de DHCPv6, pas de Teredo et pas d’ISATAP souvent utilisé en Entreprise.

Grosse déception … et en plus toujours pas d’IGMPv3 …
Il faut bien avouer que Vista/Win7 font nettement mieux dans ce domaine.

%d blogueurs aiment cette page :