\include{parameters}
\usetheme{AFNIC}
\usepackage[french]{babel}
\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{bortzmeyer-utils}

\title{Politique de gestion des ressources, notamment des adresses IP}
\author{Stéphane Bortzmeyer\\AFNIC\\\texttt{bortzmeyer@nic.fr}}
\date{2 juin 2008}

\setlength{\parskip}{15pt plus 10pt minus 10pt} 

\begin{document}

\maketitle

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}
\frametitle{Les ressources virtuelles}
Propriétés souhaitées (\emph{pas toujours}, cela dépend des applications) :
\begin{itemize}
\item Unicité (impose un registre),
\item Quasi-unicité (clés SSH ou PGP, imposent un tirage au hasard),
\item Résolvabilité (impose un protocole, des logiciels, des serveurs
ou des pairs),
\item Traçabilité, par exemple via whois (impose une hiérarchie pour
l'allocation),
\item Il existe d'autres propriétés souhaitables comme l'\emph{agrégabilité}
des adresses IP.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Les caractéristiques des ressources virtuelles}
Selon le type de ressource, elles sont :
\begin{itemize}	
\item Abondantes mais pas toutes aussi désirables (les noms de
domaine),
\item ou Rares (les adresses IPv4, les numéros de protocole IP),
\item ou encore Abondantes et équitablement désirables (les adresses IPv6, les adresses Ethernet,
ce qui n'empêche pas leur registre de faire payer très cher).
\end{itemize}

\end{frame}

\begin{frame}
\frametitle{Les registres}
\begin{itemize}	
\item Adresses IP, l'IANA, les RIR et les LIR,
\item Noms de domaine, le gouvernement US, l'ICANN, l'AFNIC, DENIC, JPRS, Nominet\ldots
\item Numéros de port ou de protocole (l'IANA),
\item Numéros de téléphone (l'UIT, l'ARCEP, les opérateurs).
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Dès qu'il y a pénurie, il y a de la politique}
\begin{itemize}	
\item Il faut allouer une ressource rare,
\item Il faut décider de qui y a droit,
\item Il faut appliquer des règles, au lieu de laisser faire le plus fort.
\end{itemize}

Bref, on a une politique d'allocation\ldots et une bureaucratie qui
doit la faire appliquer.
\end{frame}

\begin{frame}
\frametitle{Organisation de l'allocation d'adresses aujourd'hui}

\begin{enumerate}
\item Sur délégation du gouvernement états-unien,
\item L'IANA/ICANN délègue de grands blocs d'adresses « à la demande » aux
RIR,
\item Le RIR alloue des blocs plus petits à ses membres, les LIR,
\item Le LIR affecte des blocs à ses clients.
\end{enumerate}
Attention, les adresses IP posent un problème particulier, la
nécessité de respecter une certaine \emph{agrégation}.
\end{frame}

\begin{frame}
\frametitle{Les RIR}
\foreign{Regional Internet Registry}
fédérés dans le NRO (\foreign{Number Resource Organization}) :
\begin{itemize}	
\item RIPE-NCC
\item APNIC
\item ARIN
\item LACNIC
\item AfriNIC
\end{itemize}
De solides bureaucraties, bien financées, par les cotisations des LIR
et/ou la vente d'adresses. Les RIR sont l'émanation des opérateurs
Internet, leurs membres.
\end{frame}

\begin{frame}
\frametitle{Petit détour sur l'agrégation}
Les routeurs du c\oe{}ur ne peuvent pas avoir une route par adresse
IP.

Ils ont une route par préfixe. Plus les préfixes sont courts
(généraux), moins le routeur souffre.

Si on annonce en BGP \path{192.0.2.0/25} et \path{192.0.2.128/25} au lieu de
l'agrégat \path{192.0.2.0/24}, on double la consommation mémoire et
on fait bien plus que doubler le rythme des changements.

IPv6 résout complètement le problème du manque d'adresses mais pas du
tout celui de la taille de la table de routage !
% Les propositions des gros opérateurs de type « tout le monde en PA
% et seulement 8192 préfixes dans la DFZ » ne sont pas considérées.
\end{frame}

\begin{frame}
\frametitle{Pour agréger}
Les préfixes PA (\foreign{Provider-Aggregatable}) permettent
l'agrégation. Ils sont préférés par les opérateurs.

Les préfixes PI (\foreign{Provider-Independent} ou \foreign{direct
allocation} ou \foreign{micro-allocation}) permettent
l'indépendance par rapport au fournisseur. Ils sont préférés par les
utilisateurs.

Notez que beaucoup de blocs d'adresses IPv4, alloués il y a longtemps,
n'ont pas de vrai statut : ils forment le \emph{marécage}.

\end{frame}

\begin{frame}
\frametitle{Politique d'allocation d'adresses}
Ces politiques varient selon les RIR. Les principes courants :
\begin{itemize}
\item Les adresses sont affectées, pas vendues. On n'est pas
propriétaires.
\item Aucune garantie que ces adresses soient routées.
\item L'affectation se fait de préférence vers des adresses PA.
\item On doit justifier de ses demandes (« Bonjour, je me nomme
Octave, je vais héberger 10 000
serveurs dédiés chez les Ch'tis, qui seront déployés avant juin 2008 »).
\end{itemize}

Pour un comparatif des politiques des RIR
\url{http://www.nro.net/documents/nro47.html}

\end{frame}

\begin{frame}
\frametitle{Politique d'allocation d'adresses : IPv6}
La politique actuelle d'allocations IPv6 dans RIPEland est RIPE-421
\url{http://www.ripe.net/docs/ipv6policy.html}.

\begin{itemize}
\item Le LIR reçoit un /32 (ou plus général) et doit le consommer à
35 \% avant de revenir % La vraie règle est le HD-ratio, 35 \% est
		       % pour un /32
\item Les utilisateurs un bloc entre /64 et /48 (sinon, il faut le
justifier). Le RFC 3177, actuellement contesté, demandait un /48.
\item Les « services critiques » et les IXP ont droit à un préfixe PI
% La notion de service critique n'est pas parfaitement définie. Les
% serveurs DNS racine en font partie mais pas ceux des TLD
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Un cas intéressant, les adresses IPv6 PI}
En mai 2008, trois RIR acceptent d'allouer des adresses IPv6 PI (/48)
aux utilisateurs. 

Les deux autres, LACNIC et RIPE-NCC refusent encore.
\end{frame}

\begin{frame}
\frametitle{Pénurie IPv4 proche}

Geoff Huston a expliqué que la fin du monde est proche :
\url{http://cidr-report.org/presentations/2007-10-23-ipv4-depletion.pdf}.
2010 pour l'IANA, 2011 pour les RIR.  En temps réel : \url{http://www.potaroo.net/tools/ipv4/}
% http://www.potaroo.net/presentations/2007-05-09-ripe54-ipv4.pdf

Comme toutes les prévisions en sciences humaines, elle est fragile à
cause de la boucle de rétroaction (ruée lorsque les utilisateurs
prendront conscience de la pénurie).

L'ICANN a annoncé qu'il fallait penser à IPv6 d'urgence :
\url{http://www.icann.org/minutes/resolutions-29jun07.htm}. ARIN
\url{http://www.arin.net/v6/v6-resolution.html} et
LACNIC avaient fait des annonces similaires en mai 2007.

Que vont devenir les RIR ?
\end{frame}

\begin{frame}
\frametitle{Vers un marché des adresses IP ?}
Faut-il vendre des adresses ? Le marché est-il un bon allocateur de
ressources ?

La possibilité est sérieusement discutée.
% http://lists.arin.net/pipermail/ppml/2008-February/009978.html
% http://www.ripe.net/ripe/policies/proposals/2007-08.html
\end{frame}

\begin{frame}
\frametitle{La gestion du DNS et IPv6}
L'Internet dépend énormément du DNS. Le déploiement d'IPv6 est donc
lié au DNS.

\dns{ip6.arpa} est géré par les RIR et fonctionne depuis longtemps.

Un \emph{transport IPv6} des requêtes DNS est nécessaire pour les
sites purement IPv6.

Cela impose des AAAA dans \dns{root-servers.net} (et la colle dans la
racine). Fait depuis le 4 février 2008 après beaucoup de
procrastination. (Déplacer un bit dans un fichier est un exploit pour
l'ICANN.)

Avec les TLD qui enregistrent de la colle IPv6 (comme \dns{fr}), on
peut désormais avoir une chaîne de résolution DNS entièrement en IPv6.
\end{frame}

\end{frame}

\end{document}