Blog Cisco France – IPv6

Export Netflow v9 sur un transport IPv6 : ça arrive !

Je sais que beaucoup attendaient cette fonctionnalité pour basculer le management plane en IPv6, c’est disponible depuis une quinzaine de jours sur les ISR G2 (3900, 2900, 1900, 800) avec la release 15.2(2)T. Ca arrivera progressivement sur les autres plateformes… On avance!

Plus d’infos: http://www.cisco.com/en/US/docs/ios-xml/ios/fnetflow/configuration/15-2mt/cfg-de-fnflow-exprts.html

Tags: ,

Quelle portion réelle de l’internet IPv6 ready?

Et si on pondérait les allocations IPv6 par la taille des réseaux IPv4 concernés? C’est l’idée qu’a eu Rene Wihelm et qu’il nous expose brillament dans RIPE labs.

On n’aurait donc plus 47% de LIR avec un préfixe IPv6 mais on doit plutot considérer 81% de l’Internet susceptible d’être adressé en IPv6!

Idem ne parlons plus de 29% des LIR routés en IPv6: 61% de l’Internet serait déjà potentiellement routé en IPv6!

Jetez un coup d’oeil a l’article: http://readonly.labs.ripe.net/Members/emileaben/interesting-graph-ipv6-per-lir

Merci à Olivier Cahagne pour les infos!

Tags: , , ,

Flow label IPv6 : 3 nouveaux RFC ce mois-ci !

Peut-être va-t-on enfin savoir à quoi peuvent servir ces 20 bits de l’en-tête IPv6. Pour faire simple, 3 RFC sortent sur le sujet suite au dernier meeting IETF:

  • RFC6436: critique du modèle actuel (ce travail fait suite à un état des lieux publié en juin dernier dans le RFC6294)
  • RFC6437: mise à jour des anciennes spécifications (rend obsolète le RFC3697)
  • RFC6438: un exemple d’usage du flow label qui se base sur les nouvelles specs

NDLA: Peut-être aurais-je du faire pareil et poster 3 articles sur le blog pour gonfler mes stats de publication? 🙂

(more…)

Tags: , , , , ,

Vous avez bien dit 4rd ?

Rémi Despres, Rapid Deployment, Residual Deployment, Route Distinguisher… on commence a s’y perdre avec tous ces rd! Alors prenons 5 minutes pour y voir plus clair…

Tout d’abord on commence par enlever l’intrus: le Route Distinguisher réservé aux VPN MPLS, uniquement rajouté dans la liste pour complexifier un peu la donne 🙂

Bon… on commence à connaître 6rd (IPv6 Rapid Deployment), RFC 5569, plusieurs fois abordé sur ce blog: on connecte des sites IPv6 entre eux et à l’internet IPv6 via un mécanisme similaire à 6to4, mais qui utilise un préfixe IPv6 standard au lieu du 2002::/16. Utilisé entre autres par Free pour offrir un service IPv6 à ses abonnés, 6rd offre une solution pragmatique pour offrir de l’IPv6 à travers un réseau d’accès IPv4-only.

(more…)

Tags: , , , ,

2 drafts présentant des retours d’expérience de réseaux IPv6-only

Intéressant, certains commencent à mouiller un peu le maillot et jouent le jeu IPv6 à 100% ! Ils nous décrivent les tests réalisés et nous donnent leurs observations:

Pour ce test une dizaine de personnes ont accepté de travailler au quotidien sur un réseau v6-only. Leur conclusion reste que travailler dans un réseau IPv6-only est possible mais ne s’applique pas à tous, surtout en raison de problèmes au niveau de certaines applications qui ne sont pas NAT64-ables en raison du transport d’adresses IP dans les payloads. Ils suggèrent donc un déploiement basé sur du dual-stack mais n’ont pas de doutes sur la très prochaine résolution des problèmes identifiés qui permettra un modèle IPv6-only. Ci-dessous un extrait:

(more…)

Tags: , , , ,

6rd whitepaper sur Cisco.com

Un nouveau whitepaper décrivant la fonction 6rd (IPv6 Rapid Deployment) est disponible sur CCO:

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/whitepaper_c11-665758.html

Cette fonction est très utilisée dans un environnement résidentiel pour permettre une intégration d’IPv6 dans un réseau opérateur.

Tags: ,

Cisco IOS Advantage Webinars – IPv6 Deployment and Operation Experiences

Comme vous le savez peut-être, nous avons maintenant des webinars réguliers tous les trimestres sur différentes technologies. Les présentateurs sont du Network Software Technology Group, groupe ayant en charge le software de toutes les plateformes routeurs/switchs (IOS, IOX-XR et NXOS).

Tous ces webinars sont référencés sur cette page:

http://www.cisco.com/go/iosadvantage

Vous retrouvez le dernier webinar ayant trait à IPv6 sur cette page.

Geoff Huston – NANOG53

Une présentation qui vaut la peine d’y passer un peu de temps. Celle de Goeff Houston, Chief Scientist à l’APNIC, sur les difficultés et les risques d’une longue transition IPv6.

http://www.nanog.org/meetings/nanog53/presentations/Wednesday/Huston.pdf

Des slides épurés mais un contenu oh combien intéressant.

 

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

J’avais posté au milieu du mois d’août les infos ci-dessous qui sont passées un peu inaperçues devant la longueur des posts suivants sur les tests NAT64! 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. Ils sont régulièrement mis à jour et donnent rapidement la réponse à la question que nous avons le plus souvent: “quel version d’IOS faut-il pour supporter une feature IPv6 particiulière sur un produit donné?”:

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

Tags: ,

Naviguer sur un site web: combien de session TCP?

L’époque où l’on utilisait une session par application est bien évidemment révolue depuis longtemps… Chaque navigateur/OS utilise des techniques différentes pour améliorer l’expérience des utilisateurs en ouvrant simultanément plusieurs sessions TCP. Une étude montre les disparités selon les environnements: on a ratio de 1/5 entre ceux qui ouvrent le moins de session et les plus gourmands. Idem l’ouverture des sessions dans le temps n’est pas homogène entre navigateurs. J’ai réalisé dans mon lab NAT64 un petit test rapide qui met en évidence ce constat:

Site Browser Nb sessions
www.facebook.com Chrome 15
www.facebook.com Firefox 18
maps.google.com Chrome 50
maps.google.com Firefox 60
igoogle Chrome 143
igoogle Safari 35

Cela confirme que la plupart des applications grand public sont sur-consommatrices de sessions TCP. Dans l’hypothèse où cela est NATté derrière des CGN comme cela va être le cas avec les smartphones, on imagine la conséquence sur:

  • La qualité de l’expérience utilisateur
  • Scalabilité de la solution nécessaire pour accueillir les 50 milliards d’équipements mobiles attendus d’ici environ 3 ans.
  • Les coûts associés en termes OPEX/CAPEX
  • La difficulté à résoudre les problèmes et à logguer  les sessions (identification des utilisateurs et de leurs usages)

Ne vaut-il pas mieux éviter d’être NATé en revenant à un modèle end-to-end simple permis par IPv6?

Accéder à l’étude: http://opensourceaplusp.weebly.com/experiments-results.html