Après une première journée de tutorial consacré au training IPv6 , l’évènement est revenu sur les thématiques sélectionnées cette année
Durant la première matinée de cette deuxième journée , animée par Latif Ladid , président de l IPv6 Forum, les Keynotes ont permis :
– de développer le rôle de SDN pour faciliter la transition vers IPv6
– de rappeler le rôle d IPv6 dans le Machine to Machine.
– Mark Townsley Cisco Felow est revenu sur les progrès des 3 dernières années et s’est projeté sur la prochaine phase de l’adoption IPv6 : les nouvelles architectures IPv6 Centric
– Ensuite Bob Kahn (Inventeur du protocole TCP/IP) est venu présenter le principe des Handle System et les architecture DOA ( Digital Object Architecture ) spécifiée dans le document ITU-T X.1255 et décrit sur le site du CNRI http://www.handle.net/
– Et juste avant le premier break du matin, l’excellent John Curran, président de l ARIN ( Registre Internet pour l’Amérique du Nord) est venu rappeler les enjeux du passage à IPv6 d’un point de vue économique en rappelant que même s’il était toujours autant difficile de justifier économiquement le passage au sein des entreprises , il était nécessaire de continuer à provoquer ce changement en insistant auprès des hébergeurs ou en mettant la pression sur les fournisseurs en menaçant de les quitter si leur propre site Web n’était pas accessibles en IPv6. Ce qui a du raisonner dans l’oreille d’un des constructeurs leader dans la vente de Server présent dans la salle pour présenter le surlendemain ce que devait faire les entreprises et les opérateurs pour préparer leur migration vers IPv6 et qui à du avouer publiquement qu’aucun des sites web n’était justement accessibles en IPv6…un mauvais exemple a ne pas suivre ; moment de gène à ce moment là dans la salle !!
– Enfin pour conclure cette matinée , 4 speakers issus du milieu académique sont venu rappeler comment IPv6 peut jouer un rôle essentiel pour les projets IoT dont certains sont en cours de développement sous le patronage de l’ETSI pour démonter les avantages apportés par les nouveaux protocoles 6LowPAN ou CoAP
Dans la session de Mark Townsley, que j ai préféré, celui-ci est revenu sur les nombreux avantages d’une architecture IPv6 Centric dont la simplification et la transparence tout en apportant des nouveaux services. Il a rappeler pourquoi les architectures IPv4 n’arrivent plus a fournir des connexions end to end que ce soit à cause de la virtualisation L3 ou bien évidemment à cause des solutions NAT déployées dans les entreprises ou encore à cause des solutions CGN ( Carrier Grade Nat) déployées chez les opérateurs Telecom. Il a donc ensuite expliqué les promesses de simplification apportées par ces nouvelles architectures IPv6 Centric basées entre autres sur les standards :
– Homenet qui grâce au nouveau protocole HNCP (Home Networking Control Protocol) permet d auto-configurer les réseaux privés tout en prenant en charge le routage unicast et multicast de tous les réseaux IPv6 déployés localement ainsi que de faciliter la découverte de tous les services réseaux proposés localement grâce à des fonctions mDNS/DNS-SD proxy http://www.homewrt.org/doku.php?id=overview
– MAP (Mapping Address Protocol) qui permet de faire du partage d’ adresse IPv4 en mode stateless donc de manière beaucoup plus optimisée pour les équipements d’infrastructure intermédiaires sans impacter l expérience utilisateur
– SR (Segment routing) qui est une approche de type « source routing » telle que définit dans le RFC 2460 mais avec plus de flexibilité et de sécurité et dans laquelle un SR Node source (un router, un host, un server, une application, un service etc …) construit une liste de segments qu’il renseigne dans un nouveau type de « routing Header » IPv6 , le « Segment Routing header » définit dans le draft IETF draft-previdi-6man-segment-routing-header. Cette approche à plusieurs avantages dont celui de faire evoluer vers IPv6 le cœur du reseaux sans attendre que les protocoles actuellement utilisés dans les Backbone MPLS des opérateurs fassent évoluer vers IPv6 les protocoles utilisés comme LDP , RSVP-TE , FRR etc …
Comme une liste de segment peut être modifiée en cours de route, des services de fast-convergence comme FRR peuvent être basés sur SR et comme bien sur un router non-SR Node est capable d’inter-opérer avec des routers SR en ignorant le SRH ( Segment Routing Header) , la migration d une architecture classique vers une architecture de routage Segment Routing s’en trouve largement facilitée. Toutes les draft RFC et documents de travail du Working Group SPRINT a l’IETF sont disponibles ici: http://www.segment-routing.net/
Après cette matinée très riche en information sur les nouveaux protocoles autour d’IPv6, et après un excellent déjeuner, l après-midi a été découpé en 2 parties. Une première partie consacrée à des retours d’expérience et une deuxième consacrée aux mesures faites dans l’adoption d’ IPv6.
Dans cette première partie ou Chris Martin de Cisco est venu présenter en détail la technologie Segment Routing, nous avons eu droit à 3 exposés dont :
– celui de mon ancien collègue Axel Clauberg qui travaille à présent chez Deutsch Telecom et qui a développé le fameux projet TeraStream . Terastream est un des premiers réseaux déployés en production, uniquement avec de l’IPv6 entre le CPE et le Cloud basé sur une architecture NFV pour la fourniture des services triple play. Le Backbone optique est à 100Gbps et une architecture SDN qui utilise les API fournit par les protocoles NETCONF et YANG. Le premier exemple de ce projet Terastream est déployé chez l’opérateur HRVATSKI TELECOM en Hongrie (filiale de DT). Il a été pensé en Septembre 2011 et inauguré en Décembre 2012 soit 16 mois plus tard avec déjà plus de 500 clients connectés au débit Gigabit !
– Celui de mon actuel collègue Bill VerSteeg Distinguished Engineer Cisco venu expliquer les problématiques rencontrées pour fournir des services de streaming video et de Vidéo On Demand sur un Backbone IPv6 et optique à 10GBps conçu avec une architecture Multicast ASM et dans lesquelles les setupbox Cisco dotées de l’algorithme Adaptative bitRate développé par Cisco ont permis de rendre l expérience utilisateur optimale et les taches d’exploitation simplifiées
– Celui d’Erica Johnson Directrice du laboratoire d inter-opérabilité de l UNH ( University of New Hampshire ) venue présenter une nouvelle certification IPv6 ready logo consacrée aux CPE
Après une pause café bien méritée, nous avons enchainé sur le track consacré à la mesure de l’adoption d’ IPv6 au niveau mondial avec des présentations faite par Nathalie Trenaman du RIPE ( Registre Internet Européen) et par Phil Robert de l ISOC ( Internet SOCiety) et un panel animé par Alain Fiocco Senior Director chez Cisco et responsable du programme HIP ( High Impact Program) consacré à IPv6
– Nathalie Trenaman du RIPE est donc venue nous présenter le projet ATLAS basé sur 5058 sondes IPv4 et 1896 sondes IPv6 disposées chez tous ceux qui ont font la demande à l url htpps://atalas.ripe.net/apply ou qui lui demandent à l’email nathalie@ripe.net . Ces sondes sont configurées pour faire du ping , du traceroute et des requêtes DNS . Ces sondes peuvent donc démontrer la qualité de vos connexions IPv6 dont les résultats sont publiés a l url htpps://atalas.ripe.net/results.
– Phil Robert de l ISOC est lui venu présenter son site de mesure lancé au moment de l IPv6 world Launch le 6 Juin 2012 http://www.worldipv6launch.org/measurements/ et qui permet en fonction du numéro d AS de savoir combien d’utilisateur se connecte en IPv6 chez Google. Par exemple chez Cisco avec son numéro d’AS 109, nous en sommes à 13,04% ce qui s’explique par le nombre de building actuellement déployé nativement en IPv6 chez Cisco qui ne concerne que la moitié de l’ensemble de nos bureaux. Ce chiffre devrait largement croitre à partir de fin mai 2014, quand nous aurons IPv6 sur l’ensemble de nos 450 bâtiments répartis dans 369 sites eux-mêmes répartis sur 90 pays. Les détails se trouvent à cette URL http://www.cisco.com/c/en/us/solutions/collateral/enterprise/cisco-on-cisco/IPv6-Implementation_Case_Study.pdf
– Enfin , mon collègue Alain Fiocco a animé jusqu’à 19H une discussion avec David Miles de Google, John Brzozowski de Comcast, Phil Robert de l ISOC, Eric Vyncke qui représentait l IPv6 Concil de Belgique mais qui travaille chez Cisco et Matthieu Wilder représentant TELUS, un opérateur Cable et Mobile Canadien . Chacun revenant sur leur expérience personnelle du déploiement IPv6 qui avait eu lieu dans leur entreprise ou en Belgique pour notre collègue Eric Vyncke.
La troisième journée a été également divisée en plusieurs parties dont la première à été consacré à l’IoT. Nous avons donc eu :
– Laurent Toutain , chercheur à Telecom Bretagne qui est venu nous parler du projet ARESA2 financé par l’ ANR depuis 2009 et qui vise à démontrer l ‘interet d’IPv6 et des protocoles 6LowPAN dans les architectures consacrées aux projets IoT basés sur des réseaux de capteurs sans fil comme pour le smartGrid , le Machine to Machine
– Samita Chakrabarti de la société ERICSON qui est venue nous rappeler l’intérêt d’IPv6 dans les réseaux de capteurs et la création du nouveau working group créer à l’IETF « 6LO » , basé sur le protocole 6LowPAN et qui fonctionne sur les réseaux faible puissance de type Zwave, BT-LE, DECT-LE, ZigBee IP, IEEE 802.15.4 etc … et qui garanti :
- des échanges IPv6 de bout en bout avec des capteurs IoT
- un fonctionnement avec des gateway 6LO/6LowPAN
- des optimisations pour la gestion de l’énergie des devices IoT par la réduction des messages IPv6 utilisant la technologie multicast
- une réduction des MTU par compression des en-têtes IPv6
- des échanges DAD (qui servent a faire la détection d’adresses IPv6 dupliquée) rendus optionnels
- l’utilisation de table contenant les caractéristiques préalablement enregistrées
- une interopérabilité avec le protocole NDP qui peut encore être utilisé par des nœuds IPv6 classiques
Les détails sont donnés dans ce draft IETF : Draft-chakrabarti-nordmark-6man-efficient-nd.
– Sheng Jiang de la société HUAWEI est venu nous présenter les avantages des réseaux autonomic et le rôle d’ IPv6 dans cette approche simplifiée de la gestion des réseaux IPv6 en particulier dans une perspective large scale comme imposée dans les futurs réseaux IoT . On peut retrouver toutes les définitions et les objectifs Design dans le document draft-irtf-nmrg-autonomic-network-definitions.
– Fredrik Garneij de la société Ericsson est venu apporté sa vision très humoristique de l’apport d’IPv6 dans la simplification des réseaux mobile de prochaine génération dit 5G en particulier dans la réduction d’énergie et dans les applications Machine to Machine.
– Enfin le docteur Hiroshi Esaki de l’Université de Tokyo est venu présenter les travaux du MIC (Ministère des affaires Internes et de la communication) Japonais dont un guideline sur l’utilisation des Smart Community comme exemple de projet IoT utilisant IPv6. Il est aussi revenu sur certaines « Best Practises » concernant :
– la fabrication d’usines intelligentes basées sur l’utilisation des normes IEEE 1888
– des réseaux Smartgrid dont un déployé par la société TEPCO de 26 millions de compteurs
– la diffusion de contenu audio qui ont mené à une plateforme software définit pour diffuser des contenus audio numériques sur TCP/IP.
– utilisation des Datacenter avec la coopération du gouvernement de la ville de Tokyo dans lequel il a démontré des économies de 71% dans la consommation d’énergie et un ROI de 6 mois
Il a aussi décrit quelques exemples déployés sur le campus universitaire de Tokyo, dans un environnement multi-constructeurs avec 2000 points de connexions et une économie d’énergie en 2011 de 31% sur le total et de 44% sur la consommation en pointe et donc un ROI de 2 ans. Idem sur d’autres bâtiments comme celui de l’institut de technologie de Tokyo, celui qui héberge Microsoft à Tokyo, celui qui héberge la société Canon , et d’autres au Vietnam …
Le reste de la matinée a été consacré aux challenges posés par la migration IPv6 chez 2 fournisseurs de contenu notoirement connus comme Facebook et LinkedIn et un retour d’expérience sur le déploiement interne d’IPv6 chez Cisco par mon collègue Khalid Jawaid
– C’est donc d’abord Franck Martin qui travaille chez LinkedIn depuis 2 ans et qui a passé 20 ans dans les iles Fidji, qui est venu expliquer comment IPv6 a été inséré dans les 3,3 Milliards de boites mails utilisés par les 277 Millions d’utilisateurs LinkedIn dans le monde et les 247 Milliard d’email échangés chaque jour dont 70% de SPAM . C Le support d’IPv6 dans les technologies SPF et DKIM a permis de déployer les serveurs de mail de LinkedIn. Ceci est documenté à l’url : http://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-IPv6/
– Ce fut ensuite le tour de l’énigmatique Paul Saab de Facebook qui est venu rapporté son expérience de l’insertion d’IPv6 dans les réseaux internes de la société. Une fois les motivations détaillées et les choix décidés pour la partie réseau et l’affectation des /64 par rack , il a pointé les différents challenges rencontrés par les commutateurs L3 ce qui a nécessité plusieurs upgrade de milliers d’équipements . Il a ensuite expliqué les challenges rencontrés au niveau des applications développées en PHP et l’inconsistance des API dans l ‘utilisation des adresses IPv6 et qui tantôt s’attendent à utiliser des url mais trouvent des adresses IPv6 sans crochet et qui tantôt s’attendent à une adresse IPv6 et trouvent des adresses IPv6 entre crochet . idem avec celles développées en JAVA qui se comportent différemment que celles développées sur FreeBSD ou MacOS. Quelques autres problèmes ont également été expliqué avec l’utilisation de certaines librairies C trop anciennes et des ingénieurs qui ne savaient développer que du code écrit pour fonctionner en IPv4 et qu’il a fallut éduquer à l’usage de l API getaddrinfo qui rend les applications indépendantes du protocole de transport . Il est aussi revenu sur les problemes qu’on posé SLAAC dans le provisioning des adresses IPv6 sur les serveurs , et la decision de faire de l’adressage Statique, configuré par l’outil de provisioning des serveurs/VM. Il a aussi pointé les problèmes rencontrés avec MySQL et l utilisation de Curl pas du tout adapté à l’utilisation d’adresse IPv6.
– Résultats des courses malgré tout ces challenges:
- 100% des hosts fonctionnent en IPv6
- 75% du trafic interne est IPv6
- 98 % du trafic qui entre ou qui sorte des machines virtuelles est en IPv6
- 100 du trafic traité en memcache est IPv6
- la latence réseau est la même entre IPv4 et IPv6
- et la roadmap prévoit 100% de trafic IPv6 only d ici 2 ou 3 ans !!!
L’après-midi s’est poursuivi avec plusieurs exposés présentés par les opérateurs NTT, GoogleFiber, Comcast, puis par les opérateurs mobiles ROGERS Communication et EE , les constructeurs Alcatel et Juniper et aussi par un représentant de la société Technicolor ainsi que mon ancien collègue Ciprian Popoviciu de Nephos6.
Ayumu Yasuda , responsable de la recherche chez NTT est revenu sur les spécificités du déploiement d’Internet au Japon et des impacts sur IPv6. Par ailleurs il a exposé les difficultés techniques et économiques rencontrées quant a l’utilisation d’IPv6. Il a expliqué en particulier comment les ISP n’étaient pas tous égaux devant l’internet et que ca posait des problèmes pour déployer IPv6. On le comprend bien au troisième slide ou on peut voir KDDI , l’ISP le plus avancé sur IPv6 connecté directement sur Internet alors que tous les autres IPS du pays sont connectés au travers du réseau NTT-NGN donc « indirectement » , se partageant la fourniture des services triple play puisque c est NTT qui prend en charge les services VOD et téléphonie sur IP alors que l’accès Internet (data) est proposé par les ISP adossés au réseau NTT-NGN. La situation était donc la suivante : le client final se retrouve donc avec deux adresses IPv6 , une fournit par NTT-NGN et une autre par l’ISP choisi ce qui oblige le client final a reposer sur le dispositif SAS ( Source Adresse Sélection) qui permet en théorie de sélectionner son adresse source parmi les 2 proposées par NTT et l ISP en fonction de l’adresse destination. Sauf que si ce dispositif ne marche pas bien, et que le client final se retrouve à utiliser l’adresse IPv6 fournit par NTT pour aller surfer sur le WEB, le site web ne peut plus vous joindre et donc le service de base pour surfer sur Internet s’en trouve dégradé. Cette situation est en passe d’être résolue avec l’utilisation de tunnel PPPoE ou nativement en utilisant IPoE . Mais il semblerait qu’il y ait eu d’autres freins d’ordre plus économiques au développement d’IPv6 étant donné que les premières offres (jusqu en 2011) facturaient un supplément pour l’utilisation d IPv6, qu’il fallait aussi payer une autre box pour faire le PPPOE et qu’en plus le client final doit souscrire 2 contrats , un avec NTT et un autre avec l’ISP dans oublier de sélectionner les options IPv6 dans chacun des contrats . Chez OCN , le plus grand ISP japonais (avec 10 Millions de client) qui facturait IPv6 et sa box PPPoE à 90€ , IPv6 n’était quasiment jamais utilisé. NTT East/West s’apprêtent à devenir ISP avec la fourniture d’un nouveau CPE ce qui devrait déboucher sur une utilisation massive d’IPv6, le deplpoiement etant en realité deja effectif
Après la présentation de Roland Thienpont d’Alcatel-Lucent venu exposer certain modèles de deployment IPv6 dans le marché du broadband basé sur PPPoE/IPoE et sur DS-Lite , c est David Miles de Google qui est venu présenter la stratégie IPv6 de la division opérateur de Google , l’offre GoogleFibre déployée dans 3 états US pour fournir du gigabit updstream/downstream , de la TV HD etc …est basé sur une box Google fibre nativement IPv6 et managée en Cloud en IPv6 . En Mars 2013, 16% des utilisateurs étaient en IPv6 et 19% en Mars 2014.
C’est ensuite John Jason Brzozowski du Cablo-US Comcast qui a commencé très fort en rappelant que 30% de ces clients étaient déjà déployés en IPv6 , que son Backbone était à 90% IPv6 et que les 100% seraient atteint cette année avec principalement que des mises à jour software sous-entendu avec très peu de renouvellement produit mais il n a pu retenir une petite déception dans la mesure ou le trafic IPv6 a cru de 500% depuis janvier 2011 mais que ce n est pas proportionnel au niveau de pénétration , IPv6 ne représentant que 5% de son trafic Internet. Il a donc rappeler a l’ordre les compagnies qui font du CDN , les hébergeurs et les fournisseurs d’électroniques grand public pour déployer IPv6 par défaut. Il a ensuite conclu sur le projet HIPnet basé sur le déploiement de solution Homenet dans des eROUTER et sur la stratégie SDN de ComCast basée sur l’utilisation de Segment Routing jusqu au end point utilisateur et sur NFV dans le Cloud.
Dave May représentant de l’opérateur canadien ROGERS Communication présent sur le marché du Cable ( 2,5 millions de client) et de la téléphonie mobile ( 9 millions de clients) , a défendu l’approche IPv6 only sur le téléphone mobile déployé sur une infra-structure 2G/3G /4G tout en confirmant que l’utilisation de 464XLAT (RFC6877) était un succès total pour ces clients mobile.
Après la pause café de l’après-midi c est Nick Heatley du premier opérateur mobile anglais EE (join Venture 50/50 entre T-Mobile et Orange) , 29 Millions de clients (ex- Everything Everywhere) qui a présenté l’approche IPv6 only sur le téléphone mobile avec les mêmes conclusions positives que Dave May
On a ensuite eu droit à une démonstration de la part de Carl Wuyts de la société Technicolor sur l ‘utilisation d’IPv6 dans les réseaux communautaires wifi disponibles chez les ISP . Il a donc utilisé un des réseau wifi guest de l hôtel qui ne fournissait d’IPv6 pour montrer comment il pouvait récupérer de la connectivité IPv6 en utilisant des tunnels GRE et une authentification RADIUS. La démonstration a été réalaisé avec un flux vidéo tout en conservant ces capacités de roaming ce qui a été démontré in situ en débranchant la borne utilisée dans la salle pour se reconnecter avec une borne plus éloignée sans créer le moindre artifact sur l iPAD récepteur du flux Video .
Ensuite, on a poursuivi avec une présentation de Ciprian Popoviciu de la société Nephos6 qui est venu aborder le rôle d’IPv6 dans le Cloud. Apres un rappel sur les enjeux technologiques et business dIPv6 dans le Cloud et un rappel sur le fait qu’il faut profiter des transitions technologiques pour activer IPv6 y compris dans le Cloud , il a exposé les avantages d’IPv6 dans le Cloud autour de l espace infini d’adressage qui va permettre de faciliter la gestion des ressources utilisées par l infrastructure du Cloud mais aussi offrir des accès directs à ces ressources sans fractionnement réseau tout en proposant un espace d’adressage pour connecter un nombre illimité de client. IPv6 permet aussi de tirer parti des protocoles de signalisations proposer dans IPv6 en particulier avec SLAAC pour proposer des nouvelles options de provisonning d’adresses IPv6, remplacer la technologie ARP IPv4 avec NDP et faciliter le développement de nouveaux modèles d’architecture basés sur la technologie VXLAN
Ciprian est ensuite revenu sur la solution OpenStack et en particulier sur le module Reseau Neutron , anciennement Quantum, pour évoquer comment son travail (4000 lignes de code Python) et celui d’autres partenaires présents dans le projet OpenStack dont Comcast, Cisco, HP etc …) ont pu pallier aux absences de Neutron vis-avis d’IPv6 en particulier dans la communication VM vers Router dont :
– la génération des RA IPv6
– le fonctionnement de DHCPv6
– la modification des règles par défaut d ip6tables qui filtraient les paquets IPv6 ND
– et enfin sur le port externe qui ne supportait pas plusieurs familles adresses ( IPv4 + IPv6) .
Les détails de ces modifications sont documentées dans le white paper suivant : http://www.nephos6.com/pdf/OpenStack-Havana-on-IPv6.pdf
Ces modifications seront disponibles dans la prochaine release software Icehouse disponible en Avril 2014.
En conclusion de son exposé, Ciprian a écrit « Toutes les promesses du Cloud ne pourront jamais être tenues complètement sans IPv6 » ….et je ne suis pas tout seul à penser qu’il a entièrement raison sauf que les Cloud Vendor n ‘en sont pas encore tous convaincus !
C’est enfin à Alain Durand, Distinguished Engineer chez Juniper qu’est revenu le rôle de terminer cette journée en abordant un point très discuté en séance : l’utilisation de vCPE pour faciliter la transition vers IPv6 chez des opérateurs qui devraient remplacer physiquement leurs CPE ou Box pour activer IPv6 …suivez mon regard J …j ai pas dit Livebox J
L’idée ici défendue est donc de remplacer le CPE L3 qui est donc souvent une box configurée avec une fonction de routage incluant le NAT, le DHCP server, le DNS, WIFI etc …par un CPE L2 qui se limiterai à faire du WIFI mais dont toute l intelligence L3 serait déplacée dans le Cloud du SP sur une instance virtual CPE dite vCPE.
Bien que cette solution permette de réduire la presque totalité des couts associés au support client vu qu’il n y aura plus rien a configurer par le client sur son CPE, Alain a aussi fait observer que ce modèle ne permettrai pas de réduire le CAPEX des CPE de manière importante dans la mesure ou :
– la base installée des CPE L3 convertis en CPE L2 ne font réaliser aucune économie vu que ce sont les mêmes
– que les CPE L2 fraichement déployés utilisent le même hardware que les CPE L3 mais sans les fonctions L3 Activées.
et qu’à la limite, ca serait même le contraire car il faudra compter l ‘investissement hardware nécessaire pour construire la solution vCPE et y ajouter tous les couts de gestion, d orchestration , de maintenance associés.
Mais Alain à également fait observer et démonter comment la solution vCPE seraient financée par la réduction des couts réaliser sur le support client et la réduction du temps pour fournir les nouveaux services dont IPv6 !!
Dans son exemple, il estime à 5$/mois l’économie réalisée pour la mise en place du service sur un vCPE versus un CPE « traditionnel » soit 60$ /an auxquels s’ajoute 30$/an de support Client versus 50$ la mise en place d’un vCPE !!
Alain a ensuite présenté les 2 modèles de déploiement possibles avec des vCPE : intégration ou séparation des plans de forwarding et de service avec chacun leurs avantages et leurs inconvénients
Dans le modèle avec séparation des 2 plans, les fonctions L3/L4 sont réalisées dans la BNG et tous les services a valeurs ajoutés sont traités dans le Cloud ce qui nécessite une signalisation entre la BNG et le vCPE et des échanges de trafic utilisateur sur ce lien entre la BNG et le Cloud si l’utilisateur souhaite consommer plusieurs services dans le Cloud mais en revanche qui soulage le x86 qui supporte les instances vCPE.
Dans le modèle sans séparation, la BNG et le CPE restent au niveau 2 et toutes les fonctions L3/L4 jusqu’à la couche 7 sont systématiquement traitées dans le Cloud par le vCPE ce qui veut dire que le vCPE devra traiter tout le trafic utilisateur et qu’il faudra donc traiter avec précaution le dimensionnement et donc le provisoning des ressources associées.
La dernière et quatrième journée qui n’a duré qu’une matinée à démarré avec un exposé du docteur Jorge Pereira , expert IPv6 et Wifi de la commission européenne pour présenter les différents projets financés par la communauté européenne autour du WIFI et de l IPv6 partout en Europe.
Ensuite c est Jan Zorz de l’ISOC qui est venu parler des nouvelles « Best Practices » qui sont développées, au sein de l’ISOC, pour renforcer la connaissance IPv6 auprès des help desk des ISP qui fournissent le service IPv6 voire des entreprises qui le déploie dans leurs réseaux.
Ensuite c est Matthew Wilder de l’opérateur canadien TELUS qui est venu expliquer comment justifier une demande de projet IPv6 en traitant toutes les questions why ?, who ?, what ? , where ? when ? et How ? auxquelles il a du répondre en interne pour créer le service IPv6 chez Telus . L’enseignement de TELUS a été que l’activation dIPv6 dans le réseau n ‘a pas été le plus difficile contrairement au management, la configuration système et la sécurité. Qu’ils ont du ensuite passer beaucoup de temps dans la communication et la formation des techniciens et enfin qu’un grand soin doit être pris dans la définition du plan d’adressage et de la summerisation des routes IPv6 tout en gardant en tête les aspects geo-localisation et sécurité.
C est ensuite mon collègue Gunter van de Velde , Technical leader sur BGP qui est venu présenter BGP Flow Spec et son utilisation dans un réseau IPv6. Avant de laisser la parole a Tom Coffeen d’infoblox qui est venu parler d’IPv6 et ce que peut apporter DHCP Fingerprinting dans un réseau IPv6 qui fait du BYOD et qui doit ,à court terme, permettre d’intégrer les 219 Millions de devices BYOD recensé en fin d’année 2012 dont 22% sont des devices Apple et 29% des devices Samsung livrés par défaut avec le protocole IPv6 activé et surtout non désactivable.
On est donc dans la problématique ou IPv6 est présent dans le réseau d’entreprise mais souvent de manière invisible.
Il a donc rappeler ce qu’est DHCP fingerprinting , le but étant de permettre d’identifier le type de device et l’OS utilisé a partir d ‘une requête DHCP basique faite par un device client. En IPv4, l’option DHCP 55 est utilisée par le client pour obtenir de la part du server , une liste de 17 paramètres . Ces 17 paramètres sont ensuite comparée a une base de données entretenue par Fingerbank https://www.fingerbank.org qui compte 251 identifiants unique pour DHCP et qui permet, par exemple d’identifier un OS Fedora avec la liste 1,28,2,121,15,6,12,40,41,42,26, 113, 3, 121, 249, 252 et 42.
Dans un environnement BYOD, ces paramètres peuvent être complétés par des informations fournit par un portail captif par exemple . Chez Infoblox, le DHCP fingerprinting a permit d’identifier 78 devices avec identifiant unique et dans 81% des cas ,l’OS a été déterminé .
En IPv6, l’ »option request » utilisée par le client dans la requête DHCP Sollicit est l’option 6 ( Ca tombe bien J ) sauf qu’il y a très peu de paramètres de renseignés. Il faut donc compléter avec d’autres champs sollicités dans la requête DHCP comme le champs « Vendor Class » et « client identifier » voire corréler les informations avec celles obtenues en IPv4, quand le device est déployé en dual-stack. Les paramètres 1,6,23,24, 8 et 3 permettent d’identifier un Fedora version 17.
Malheureusement, ces informations varient d’une version d’OS à l’autre . En Windows8, la requête se fait sur les paramètres 8,23,24,17 et 39 alors qu’en Windows7, c est sur la liste 6,24,23 et 17 alors que ca reste consistent entre un MacOS 10.8 et une Ubuntu 12.04 mais uniquement avec les valeurs 6,24,23.
Infoblox en collaboration avec l UNH va travailler sur un base de données publique concernant les paramètres utiliser avec DHCPv6.
La Matinée s’est poursuivie avec un rapide exposé de mon collègue Andrew Yourtchenko , Technical Leader IPv6 sur les statistiques IPv6 observées pendant l évènement et a comparé avec l’édition 2013 et montrer une augmentation tres sensible a la fois de la proportion de device et du volume de traffic .
Timothy Winter de l’UNH ( University du New Hampshire) est revenu parlé du nouveau IPv6 logo pour CPE avant que mon Collègue Mark Townsley Cisco Fellow vienne présenter la technologie Homenet et les avancées réalisées avec le protocole HNCP dont j ai déjà parlé plus avant dans ce compte rendu.
Voilà qui conclue donc mon compte rendu de ces 3 jours et demi de sessions. Ce fut comme les précédentes années un excellent cru.
Même si tout n’est pas parfait , on a pu voir que le déploiement d’IPv6 avait bien progressé en particulier chez les opérateurs mobiles , que des nouvelles architectures IPv6 Centric étaient de plus en plus utilisées par les opérateurs et que même si l’urgence de se préparer à IPv6 se renforce , il ne faut pas négliger l’utilisation d’une certaine méthodologie avec un certain nombre d’étapes intermédiaires très importantes comme :
– identifier son business case IPv6
– demander son préfix
– commencer à se former
– démarrer les Assessements hardware et software sans oublier les applications
– réfléchir à son plan d’adressage et à son design
– commencer les phases de tests
– et basculer en production !!
Voilà j’espère avoir été complet et à la prochaine fois !!!
Authors
