IPv6 - L'affaire de tous Disponibilité d’adresses IPv4 ...

squaddinnerladyΛογισμικό & κατασκευή λογ/κού

2 Ιουλ 2012 (πριν από 5 χρόνια και 20 μέρες)

350 εμφανίσεις




Décembre 2011



IPv6
-

L'affaire de tous

Disponibilité d’adresses IPv4

: état des lieux des
stocks

Depuis qu’il existe, l'Internet est un média en pleine expansion. Le nombre

d’équipements connectés n’a
cessé d’augmenter. Avec une croissance exponentielle
de l'Internet au

cours de la dernière décennie, le nombre fini d’adresses IPv4

unique
mondiale (4 Milliards)
est
maintenant
presque épuisé.

Pour bien comprendre ce
point il convient de regarder précisément l’état des lieux des stocks et les
mécanismes d’allocation des adr
esses.


Le modèle d’allocation d’adresses est hiérarchique

: un registre mondial (l’IANA)
alloue des préfixes aux RIR (Regional Internet Registries) qui sont

:



ARIN

: Amérique du nord



RIPE NCC

: Europe et moyen orient



APNIC

: Asie
-
Pacifique



LACNIC

: Amériq
ue latine



AFRINIC

: Afrique

Chaque RIR alloue sur demande des préfixes à ses membres (LIR


Local Internet
Registries) qui sont pour simplifier les opérateurs qui à leur tour vont distribuer des
adresses à leurs clients.


Depuis février 2011,

l’IANA n’a pl
us d’adresses IPv4 en stock

; les derniers préfixes
ont été distribués équitablement entre les 5
registres régionaux
. L’APNIC a
également
épuisé son stock

peu après
, et il est prévu que celui du RIPE NCC soit vide
mi
-
2012.

Un opérateur
européen
à cette dat
e ne pourra
donc
plus obtenir de
nouveaux préfixes IPv4.

I
l ne sera pas
non plus
possible pour une entreprise
d’obtenir des
préfixes de type PI (Provider

Independent), pourtant absolument
nécessaires quand cette dernière veut être multi
-
homée.



Impact sur l
’Internet

L’é
puisement des adresses IPv4 a

un impact majeur sur la croissance de l'Internet et
des fournisseurs

d’accè
s
à

Internet (FAI). Tout FAI qui souhaite
ra

continuer à
accroitre ses revenus en augmentant sa base client devra trouver une technique
pou
r ajouter des utilisateurs à Internet sans nécessiter de nouvelles adresses IPv4
publiques supplémentaires.
La solution
conçue il y a déjà plusieurs années
est un
nouveau protocole Internet offrant un espace d’adressage quasi illimité

: IPv6.
Il n'y
a pas
d’alternative

: l
a seule question qui se pose est quand et comment
la

transition
d’IPv4 vers IPv6 va se produire.


A ce stade il est important de rappeler qu’
IPv6 n'est pas directement compatible
avec IPv4

: un
nœud
uniquement IPv4 ne peut pas communiquer
avec u
n nœud
uniquement IPv6 (et vice
-
versa). Alors que IPv4 et IPv6 ne sont pas compatibles, ils
peuvent utiliser le même réseau simultanément, et divers
es

technologies visent à
l'intégrati
on et la coexistence IPv4/IPv6.

Croyance populaire

: «

J’ai suffis
amment d’adresses IPv4,
je n’ai pas
besoin de passer en IPv6…

»

Cette remarque

est souvent la première qui est faite par nos clients quand nous
commençons à leur parler d’IPv6. Généralement nous arrivons en quelques minutes
à susciter tout l’intérêt de nos

interlocuteurs qui comprennent rapidement en quoi
tout le monde est concerné.

Internet
=

interdépendance

Tout d’abord il convient de rappeler que sur un réseau, les problématiques de l’un
sont toujours les problématiques de l’autre. Tous les réseaux étant

interconnectés,
ils sont forcément interdépendants. Un opérateur
A
ne pourra donc pas
trop
se
réjouir de pannes chez son concurrent
B
puisque ses propres clients
sont
également
impactés

s’
ils doivent
accéder à des services hébergés chez
B
… L’usage
r au fin
al ne
se soucie guère du

fautif

: «

ça ne marche pas

» et on ne
cherche pas à aller
plus
loin



Pour IPv6 on retrouve cette interdépendance

:

si l’adoption globale d’IPv6 prendra
du temps il reste essentiel que les applications fonctionnent correctement
pendant
la phase de transition.

U
ne
PME
qui fournit des services en ligne ne voudra par
exemple pas se couper
d’un usager connecté sur un réseau mobile de quatrième
génération, et qui ne disposerait que de connectivité IPv6.

De même, une grande
entreprise
française, amenée à coopérer fortement avec des industries en Asie ne
souhaitera pas se couper de ces dernières si elles n’ont plus la capacité à parler IPv4.


La translation

et ses pièges

Bien évidemment, que l’on parle IPv4 ou IPv6, des solutions sont po
ssibles pour faire

de la translation d’adressage de IPv4 à IPv6 et vice
-
versa

: on parle d’AFT (Address
Family Transation).
L’opérateur 4G

mentionné précédemment

aura bien sûr pris soin
de permettre à ses usagers «

IPv6
-
only

» d’accéder à des services IPv4 via une
translation effectuée au cœur du réseau. On parle de
solutions de
type
CGN (Carrier
Grade NAT).


La solution fonctionne mais a certaines limitations

:


1.

S
eules des noms
d’hôtes DNS peuvent
être traduits

(il est impossible de
traduire des adresses IPv4 qui seraient renseignées au niveau de
l’application)

2.

L
es protocoles qui embarquent des adresses IP dans la couche applicative
(par exemple FTP, SIP…) nécess
itent des ALG (Application Level Gateways),
déploiements spécifiques qui peuvent être coûteux

et gourmands en
ressources.

3.

L’adresse source est perdue. Cette dernière est souvent utilisée par de
nombreux fournisseurs de services en ligne pour offrir des pr
estations
proches de leurs clients. Notons que certains mécanismes existent pour
contourner le problème

: ils seront décrits dans la suite de cet article.

4.

Un mauvais
dimensionnement

peut se révéler être catastrophique
. En jouant
sur les ports TCP sources
et destination, on peut
faire correspondre

2
16

couples
{
adresse IPv6

; port
}

sur une même adresse IPv4.

Les ressources
semblent donc quasi illimitées
, e
t pourtant il suffit de quelques tests pour
comprendre
que tout n’est pas si simple
.
Les applications qu
i utilisent un seul
port TCP font bel et bien parti
e

du passé. Le tableau 1 indique le nombre de
ports utilisés pour quelques applications (tests réalisés dans un lab de CISCO
France


source http://ipv6blog.cisco.fr)


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

Tableau 1


nombre de ports utilisés par application


L’opérateur
du NAT64
doit définir combien de
translations
sont autorisé
e
s
par client
(pour éviter qu’un seul client utilise à lui tout seul toutes les
ressources).

D’un côté il doit économiser un maximum les ressources, de
l’autre il doit s’assurer

que les applications continueront à fonctionner. Un
mauvais dimensionnement a des impacts immédiats. Ci
-
dessous nous voyons
une carte de Google Map ©
avec une limite de 15

sessions TCP

: les résultats
sont inexploitables et cela illustre bien en quoi le NAT n’est pas transparent
pour le service

s’il n’est p
as adapté
.



Figure 1


Impact d’un NAT sous
-
dimensionné sur Google Map ©


5.

D
ifficulté de résolution de problèmes complexes

et limite de responsabilité
.
Comme pour
le
NAT44

auquel nous nous sommes habitués
, NAT64 introduit
une nouvelle brique dans le
réseau qu’il fa
ut administrer. Quand
celui qui
gère le contenu (ou service) administre également le mécanisme de
translation, il prend l’entière responsabilité du service global, c’est
-
à
-
dire de
sa disponibilité aussi bien sur IPv4 ou IPv6. Il prendra alor
s soin de réserver
assez de ressources (ports) par client et la limite de responsabilité est claire.
En revanche si
une
entreprise laisse à
un tiers
le soin de gérer la translation
alors il prend le risque que les ressources mises en place ne correspondent

pas à ses besoins.

Développer sa p
résence Internet IPv6

: la priorité #1 pour l’entreprise

Pour les
raisons
précédemment décrites, il apparaît que la première étape pour
l’entreprise
doit
être de déployer IPv6 sur sa présence Internet
, afin de ne pas
dépe
ndre d’un mécanisme de translation tiers
inadapté
. Cette présence internet

est
traditionnellement constituée de trois services au minimum

: m
essagerie

électronique,
WEB et DNS.
Ajouter IPv6 à ces trois services permettra à l’entreprise
d’être présen
te sur
l’internet IPv4 et IPv6 et de ne pas se couper de ses partenaires
et
de
ses clients.
Les fonctions de support opérationnel et les procédures de gestion
du réseau doivent également être migrée
s

en IPv6.


Construire sa présence Internet IPv6

Les procédures e
t les prérequis peuvent varier de manière importante entre les
entreprises et les services qu’elles souhaitent exposer à Internet. Nous allons
étudier les plus courants.


Obtenir un espace d’adressage IPv6 public

Les blocs d’adresses IPv6 sont distribués
de la même manière que les préfixes IPv4
(voir début de l’article). Les opérateurs Internet peuvent fournir des espaces
d’adresses de type PA (Provider Aggregatable) à leurs clients. Ces préfixes seront
agrégés

par l’opérateur et ne seront pas spécifiqueme
nt visibles dans l’internet. Tant
que l’entreprise n’est pas multi
-
homée, un préfixe PA est suffisant. Sinon, il devient
nécessaire de demander un préfixe IPv6 de type PI (Provider Independant)
. L
es
procédures d’allocation
et les coû
ts relatifs aux adresse
s PI peuvent
varier
légèrement selon les registres.


Ajouter IPv6 aux serveurs WEB

Ajouter IPv6 dans sa présence internet peut, dans un premier temps, se limiter à
implémenter IPv6 sur les frontaux WEB. Il n’est pas absolument pas nécessaire de
mettre à
jour les bases de données et les Back
-
end serve
u
r
s

en IPv6 étant donné
qu’ils ne sont justement pas directement connectés à Internet. Il y a plusieurs
façons d’ajouter de la connectivité IPv6 à une ferme de serve
u
rs WEB :




A
jouter nativement IPv6 aux
serve
u
rs WEB IPv4 existants

:
c
onfigurer IPv6
sur le serve
u
r WEB lui
-
même (Apache, IIS et la plus
-
part des autres server
WEB récents disposent tous d’IPv6 depuis des années) et sur les équipements
de partage
de
charge. C’est

certainement la manière la plus

efficace pour
supporter IPv6 mais certaines applications,
ainsi que
les scripts utilisés sur ces
serveurs
,

peuve
nt nécessiter des changements
lourds
(
en particulier s’ils
utilisent ou stockent l’adresse source de leurs clients).



Ajouter IPv6 nativement su
r des serveurs WEB dédiés

: configurer des
serveurs WEB dédiés séparément de l’infrastructure IPv4. Cette option à
l’avantage de réduire au maximum la dépendance aux autres composants
voire même permettre une sélection entre les différents hébergeurs de
co
ntenu pour IPv4 et IPv6
.



Utilisation de fonctions AFT (Address Family Translation) dans un
équipement de partage de charge
. L
es équipements de partage
de
charge les
plus récents sont capables de connecter des clients IPv6
-
only vers des
serveurs IPv4
-
only.
Ces équipements font de la translation entre les deux
familles d’adresse IPv4 et IPv6. C’est probablement le moyen le plus simple
de rentre un serveur WEB IPv4 accessible en IPv6
. Sans aucune configuration
spécifique, certaines informations ne sont
malheur
eusement
pas renseignées
dans les log des serveurs WEB
,

car les clients IPv6 apparaissent avec une
unique

adresse IPv4. Certains équipements de partage de charge peuvent
insérer le champs XFF (X
-
Forwarded
-
For) ainsi l’en
-
tête http peut conserver
l’adresse
IPv6 du client et permettre au serveur IPv4 de la stocker dans ses
logs.



Utilisation de fonctions AFT dans des « proxy reverse WEB »

: Si un reverse
proxy est utilisé (souvent pour des raisons de sécurité), ils peuvent de la
même manière être utilisés pou
r faire de l’AFT avec les mêmes précautions à
prendre qu’avec les load
-
balancer concernant le logging de l’adresse IPv6
source du client.



Utilisation de la fonction AFT dans les équipements réseau (route
u
r
s
)

: En
2010, l’IETF a finalisé les spécifications
de la technologie AFT (stateless et
statefull) proposée dans un équipement réseau quand la connexion est
initiée par un host
IPv6
-
Only vers un serveur IPv4
-
o
nly. Les constructeurs ont
prévu de le proposer entre 2011 et 2012. C’est un autre moyen très simpl
e
d’ajouter IPv6 dans sa présence Internet sans modifier les frontaux WEB IPv4
actuellement en production.


Ajouter IPv6 dans le service de messagerie.

L’expédition et la réception d’un
email sur Internet sont réalisée
s avec le protocole
SMTP (Simple Mail

Transfer Protocol) au dessus du protocole TCP (Tran
sport Control
Protocol). La plu
par
t des MTA (Mail Transfer Agent)

sont

capable
s

de fonctionner en
IPv6. Cependant, certaines fonctions particulières

co
mmunément déployé
e
s dans les
MTA

ne supportent pas en
core IPv6. Parmi ces fonctions, il y a le blacklisting et les
services de réputation utilisés par les logiciels de lutte contre le SPAM. Au fur et à
mesure que le trafic de messagerie IPv6 va augmenter, le SPAM IPv6 augmentera lui
aussi

et les outils devro
nt évoluer.


Un certain nombre d’entreprise
s

utilisent des scripts pour trier les logs

des serveurs
de messagerie
. IPv6 modifie de fait le format de ces logs. Comme avec d’autres
services, certaines précautions devront être prises pour s’assurer que de tel
les
fonctions de gestions sont bien capables de supporter IPv6.


Actuellement,
bon nombre de

serveurs de mail IPv4 rejettent des mails entrants
émis par des serveurs appartenant à des domaines
qui ne sont
pas correctement
configurés. La même chose arrivera

avec des serve
u
rs de mail
mal renseignés
en IPv6

dans le DNS
. La configuration correcte du DNS sera donc plus qu’un prérequis pour
les serveurs IPv6 exactement comme cela est fait actuellement pour IPv4.


Ajouter IPv6 dans le DNS (Domain Name System)

DNS
est bien évidemment la pièce critique de la prés
ence Internet. C’est lui
qui
ann
once l’
adresse
IP

des serve
u
rs de messagerie et des server WEB
, qu’elle soit IPv4
ou IPv6.


Il y
a deux étapes pour permettre à un serve
ur DNS de supporter IPv6

:



Information I
Pv6 dans les zones DNS
: a
jouter les adresses IPv6 de tous les
serveurs publics dans la base de donnée DNS. Cette opération est
simplement
réalisée en ajoutant des RR (Re
source Record) avec les adresses
IPv6 (Ces enregistrements sont appelés AAAA)
.

Dans l
e but de faciliter la
configuration et le troubleshooting, il est aussi préférable d’ajouter un
reverse mapping entre l’adresse IPv6 et le FQDN (Fully Qualified Domain
Name). Pour les serveurs Dual
-
Stack, il faut prévoir deux enregistrements par
FQDN, un p
our IPv4 (Type A) et un autre pour IPv6 (Type AAAA).



Le transport IPv6 des informations DNS
: le server DNS accepte les requêtes
sur un transport IPv6 et répond sur un transport IPv6. Il est beaucoup plus
courant de configurer son DNS en dual
-
stack ainsi i
l pourra accepter des
requêtes et
y
répondre sur un transpor
t IPv4 et un transport IPv6.


Il est important de noter que ces deux étapes sont indépendantes. On peut
configurer l’une sans l’autre. Dans le but de mettre IPv6 dans sa présence Internet,
seule
la première étape est requise ainsi une entreprise peut publier les a
dresses
IPv6 publiques de tous s
es serveurs Internet IPv6.


Tous les servers DNS importants du marché supportent IPv6 (ISC BIND, Cisco
Network Registrar, Microsoft DNS Server).


Ajouter
IPv6 aux fonctions d’administration de réseau

Tous les outils qui surveillent l’activité du réseau devront être vérifiés pour s’assurer
qu’ils pourront traiter correctement le format des adresses IPv6. IPv6 nécessite que
les outils d’administration utilise
nt bien les nouvelles MIB avec le protocole SNMP.
De la même manière, tous les outils qui sont utilisés pour l’analyse et l’inspection de
trafic réseau ou le contrôle d’accès doivent être également vérifiés.

Conclusions et recommandations

Bien que les opér
ateurs réseau soient aujourd’hui les plus concernés par la
raréfaction des adresses IPv4, les entreprises doivent rapidement valider leur
exposition à l’internet IPv6.
En plus de
règlementations
qui risquent d’imposer IPv6
,
d’autres facteurs
vont jouer

: s
écurité, support de nouvelles applications,
affranchissement des passerelles

NAT, facilité

de

déploiement



La
présence Internet
d’une entreprise est l’ensemble des
service
s

qu’elle affiche
à
ses clients ou à ses partenaires Internet.
Amener IPv6 sur cette

présence Internet
doit être la première priorité. Cela peut être réalisé progressivement à
l’aide

de
reverse proxies, routeurs, l
oad
-
balancer (équipements de partage de cha
rge) f
aisant
de la translation entre des internautes IPv6
-
Only et les serveurs IPv4

d’entreprises.

Il
s’agit d’un projet global qui ne concerne pas uniquement le réseau mais toute
l’informatique de l’entreprise. En ce sens une dynamique de projet global doit être
entr
e
prise.


Les étapes suivantes seront
de permettre aux employés et aux
applications
d’accéder à des contenus ou à des services présents en IPv6 sur Internet. C
ela sera
particulièrement
vrai pour de

nouvelles entreprises connectées sur Internet une fois
que les adresses IPv4 ne seront plus disponibles
. Cette problématique fera

l’objet de
prochains articles.





Contactez
-
nous :

www.cisco.fr

0800 907

375




Siège social
Mondial

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134
-
1706

Etats
-
Unis

www.cisco.com

Tél. : 408 526
-
4000

800 553 NETS (6387)

Fax : 408 526
-
4100

Siège social France

Cisco Systems France

11 rue Camille
Desmoulins

92782 Issy Les
Moulineaux

Cedex 9

France

www.cisco.fr

Tél. : 33 1 58 04 6000

Fax : 33 1 58 04 6100

Siège social Amérique

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134
-
1706

Etats
-
Unis

www.cisco.com

Tél. : 408 526
-
7660

Fax : 408 527
-
0883

Siège social Asie Pacifique

Cisco Systems, Inc.

Capital Tower

168 Robinson Road

#22
-
01 to #29
-
01

Singapour 068912

www.cisco.com

Tél.
: +65 317 7777

Fax : +65 317 7799


Cisco Systems possède plus de 200 bureaux dans les pays et les régions suivantes.
Vous trouverez les adresses, les numéros de
téléphone et de télécopie à l’adresse suivante :

w w w . c i s c o . c o m / g o / o f f i c e s

Afrique du Sud • Allemagne • Arabie saoudite • Argentine • Australie • Autriche • Belgique • Brésil • Bulgarie • Canada
• Chili Colombie • Corée Costa Rica • Cro
atie • Danemark • Dubaï, Emirats arabes unis • Ecosse • Espagne • Etats
-
Unis
• Finlande • France Grèce • Hong Kong SAR Hongrie • Inde • Indonésie • Irlande • Israël • Italie • Japon • Luxembourg •
Malaisie Mexique • Nouvelle Zélande • Norvège • Pays
-
Bas •

Pérou Philippines • Pologne • Portugal • Porto Rico •
République tchèque • Roumanie • Royaume
-
Uni • République populaire de Chine • Russie Singapour • Slovaquie •
Slovénie • Suède Suisse • Taiwan • Thaïlande • Turquie • Ukraine • Venezuela • Vietnam • Zi
mbabwe


Note:

Copyright © 2009 Cisco Systems, Inc. Tous droits réservés. CCSP, CCVP, le logo Cisco Square Bridge,
Follow Me Browsing et StackWise sont des marques de Cisco Systems, Inc. ; Changing the Way We Work, Live, Play, and
Learn, et iQuick Study sont

des marques de service de Cisco Systems, Inc. ; et Access Registrar, Aironet, ASIST, BPX, Catalyst,
CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, le logo Cisco Certified Internetwork Expert, Cisco IOS, Cisco Press, Cisco Systems
, Cisco
Systems Capital, le lo
go Cisco Systems, Cisco Unity, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast,
EtherSwitch, Fast Step, FormShare, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, le logo iQ, i
Q Net
Readiness Scor
ecard, LightStream, Linksys, MeetingPlace, MGX, le logo Networkers, Networking Academy, Network Registrar, Packet,
PIX, Post
-
Routing, Pre
-
Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StrataView Plus, TeleRouter, The Fastest Way
to Increa
se Your Internet Quotient et TransPath sont des marques déposées de Cisco Systems, Inc. et/ou de ses filiales aux États
-
Unis et
dans d’autres pays.

Note:

Toutes les autres marques mentionnées dans ce document ou sur le site Web appartiennent à leurs
propriétair
es respectifs. L’emploi du mot partenaire n’implique pas nécessairement une relation de partenariat entre Cisco et une
autre société. (0502R) 205534.E_ETMG_JD_10/09