Re: [FRnOG] RFC 6204: Basic Requirements for IPv6 Customer Edge Routers
Le 5 mai 2011 18:26, Mohsen Souissi mohsen.soui...@nic.fr a écrit : On 28 Apr, Jérôme Nicolle wrote: [...] | Principal problème : ces CPE embarquent généralement un relay DNS qui | ne répond qu'en v4, l'annonce du service de résolution par | RA(http://www.bortzmeyer.org/5006.html) n'est pas proposé. == Pour info/rappel, ce RFC rendu a été rendu obsolète par RFC 6106, et Stéphane ne l'a pas raté ;-) http://www.bortzmeyer.org/6106.html Au passage, je partage avec vous excellente page web du RFC-Editor qui permet de voir *dans les deux sens* quel RFC met à jour ou rend obsolète quel(s) RFC : http://www.rfc-editor.org/rfcsearch.html Vous pouvez essayer par exemple avec 1884 or 1885 et suivre la chaîne pour voir l'utilité de l'outil en termes de traçabilité/versioning. Mohsen Tu veux dire que ca peut remplacer un Stéphane (sur la partie veille RFC), dans le sens où c'est accessible 24/7 ? :)
Re: [FRnOG] RFC 6204: Basic Requirements for IPv6 Customer Edge Routers
On 06 May, Nicolas CARTRON wrote: | Le 5 mai 2011 18:26, Mohsen Souissi mohsen.soui...@nic.fr a écrit : [...] | http://www.rfc-editor.org/rfcsearch.html | | Vous pouvez essayer par exemple avec 1884 or 1885 et suivre la chaîne pour | voir l'utilité | de l'outil en termes de traçabilité/versioning. | | Mohsen | | Tu veux dire que ca peut remplacer un Stéphane (sur la partie veille RFC), | dans le sens où c'est accessible 24/7 ? :) == ça ne résume/traduit pas les RFC (en français)... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] RFC 6204: Basic Requirements for IPv6 Customer Edge Routers
Bonjour, On 28/04/2011 09:44, Stephane Bortzmeyer wrote: Pour tous ceux qui livrent à leurs clients des boxes IPv6, voici une utile check-list pour tester avant : RFC 6204 : Basic Requirements for IPv6 Customer Edge Routers http://www.bortzmeyer.org/6204.html Pour ceux que cela intéressent, les gens d'ipv6ready.org travaillent sur une spec de tests et des jeux de tests en préparation pour tester la conformité à cette RFC: http://www.ipv6ready.org/?page=public-review-cpe Cdlt, -- Mathieu Goessens, IRISA, Campus de Beaulieu, 35042 Rennes cedex, France Tel: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] RFC 6204: Basic Requirements for IPv6 Customer Edge Routers
On 28 Apr, Jérôme Nicolle wrote: [...] | Principal problème : ces CPE embarquent généralement un relay DNS qui | ne répond qu'en v4, l'annonce du service de résolution par | RA(http://www.bortzmeyer.org/5006.html) n'est pas proposé. == Pour info/rappel, ce RFC rendu a été rendu obsolète par RFC 6106, et Stéphane ne l'a pas raté ;-) http://www.bortzmeyer.org/6106.html Au passage, je partage avec vous excellente page web du RFC-Editor qui permet de voir *dans les deux sens* quel RFC met à jour ou rend obsolète quel(s) RFC : http://www.rfc-editor.org/rfcsearch.html Vous pouvez essayer par exemple avec 1884 or 1885 et suivre la chaîne pour voir l'utilité de l'outil en termes de traçabilité/versioning. Mohsen. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] RFC 6204: Basic Requirements for IPv6 Customer Edge Routers
Pour tous ceux qui livrent à leurs clients des boxes IPv6, voici une utile check-list pour tester avant : RFC 6204 : Basic Requirements for IPv6 Customer Edge Routers http://www.bortzmeyer.org/6204.html Auteur(s) du RFC: H. Singh, W. Beebee (Cisco), C. Donley (CableLabs), B. Stark (ATT), O. Troan (Cisco) Ce RFC du groupe de travail v6ops http://tools.ietf.org/wg/v6ops, qui se consacre aux problèmes pratiques du fonctionnement d'IPv6 (sans modification des protocoles, donc), porte sur les CPE (Customer Premises Equipment), alias CER (Customer Edge Routers), alias home gateway, qui sont les boîtiers installés chez l'utilisateur domestique ou petite entreprise. Par exemple, en France, la Freebox ou la DartyBox sont des CPE. Certains d'entre eux gèrent le protocole IPv6 et ce RFC résume tout ce que doivent savoir les concepteurs de ces « boxes » pour faire de l'IPv6 proprement. Le gros débat qui avait eu lieu à l'IETF lors de la conception de ce RFC portait sur une règle exprimée dans les premières versions de l'Internet-Draft qui avait précédé le RFC : cette règle disait qu'un CPE IPv6 devait, par défaut, bloquer les connexions entrantes. L'argument principal était que les CPE IPv4 font tous cela. Mais ils le font parce qu'en IPv4, la pénurie d'adresses http://www.bortzmeyer.org/epuisement-adresses-ipv4.html oblige à des bricolages comme le NAT, et empêchent de toute façon les connexions entrantes. IPv6 permettant enfin de récupérer une adresse IP unique mondialement, et donc d'avoir à nouveau une connectivité de bout en bout, cette règle évoquait plus un « Minitel 2.0 http://www.fdn.fr/internet-libre-ou-minitel-2.html » que l'Internet du futur. Elle a donc été retirée de ce RFC, qui laisse ouverte la question de la sécurité, la déléguant à un autre document, le RFC 6092. En coupant les connexions entrantes, on bloque certaines attaques (par forcément les plus fréquentes : aujourd'hui, la plupart des attaques se font par le contenu des données transférées - importation de malware - et pas directement sur IP) mais on empêche les utilisateurs de profiter des services comme la téléphonie sur IP ou le pair-à-pair, qui dépendent souvent de cette possibilité de connexions entrantes. Donc, en dehors de ce point, que contient ce RFC ? La section 1 résume les points importants : le RFC se focalise sur le cas où IPv6 est natif (pas de traduction d'adresses entre v4 et v6), et sur le cas simple où il n'y a qu'un seul CPE, qui récupère sa configuration sur le WAN, puis la distribue aux machines IPv6 locales, puis route leurs paquets. Le déploiement de l'IPv6 dans le réseau de l'opérateur n'est pas discuté (cf. RFC 4779). Ce RFC concerne uniquement le « foyer, doux foyer ». D'abord, un rappel du fonctionnement d'un CPE IPv4 aujourd'hui. Ce fonctionnement n'est spécifié nulle part, il résulte d'une accumulation de choix par les auteurs anonymes des CPE existants. Ces choix sont souvent erronés http://www.bortzmeyer.org/home-gateway.html. En l'absence de norme formelle, la section 3.1 décrit le CPE « typique » de 2010. Ce CPE typique a une (et une seule) connexion avec l'Internet, une seule adresse IP publique (et encore, parfois, il y a même du NAT dans le réseau de l'opérateur) et il sert de routeur NAT aux machines IPv4 situées sur le réseau local. Par défaut, en raison du NAT, il bloque toutes les connexions entrantes (c'est la seule allusion à cette question qui soit restée dans la version finale du RFC). Ouvrir des ports entrants (port forwarding) se fait par une configuration manuelle du CPE, via une interface Web (cas de la Freebox) ou bien par UPnP. C'est donc un vrai Minitel 2.0 http://www.fdn.fr/internet-libre-ou-minitel-2.html. Un avantage de ces adresses privées est toutefois d'assurer la stabilité des adresses internes : elles ne changent pas si on quitte son FAI. L'architecture ci-dessus est largement déployée et correspond au cas de la plupart des abonnés à l'Internet à la maison. À quoi ressemblera t-elle en IPv6 ? On ne peut évidemment pas encore être sûr. mais la section 3.2, qui la décrit en termes très généraux, suppose qu'elle ne sera pas très différente, à part que la présence de plusieurs réseaux (et donc plusieurs préfixes IP) sera peut-être un cas plus fréquent qu'aujourd'hui. Quelles adresses IP seront utilisées à l'intérieur ? On pense immédiatement au RFC 5902, qui n'est toutefois pas cité. Le RFC 6204 présente la possibilité que des adresse locales, les ULA (RFC 4193) soient utilisées pour le réseau local. Le CPE devra bien alors fournir un mécanisme de traduction. Alors, maintenant, quelles sont les exigences auxquelles devront se plier les futurs CPE IPv6 ? La section 4 est la liste de ces demandes. Elles sont nombreuses. Citons, parmi elles, l'obligation de d'abord se comporter en bon routeur, ce qui implique par exemple de mettre en #339;uvre ICMP (RFC
Re: [FRnOG] RFC 6204: Basic Requirements for IPv6 Customer Edge Routers
Le 28 avril 2011 09:44, Stephane Bortzmeyer bortzme...@nic.fr a écrit : Les CPE d'aujourd'hui mettent-ils en #339;uvre ces recommandations ? Difficile à dire, je ne connais pas d'étude systématique ayant été faite sur les capacités de ces engins, mais ce serait certainement très instructif. Les premiers firmwares v6-enabled (beta-grade) de quelques fabricants de CPE chinois commencent à arriver. Pour ceux que j'ai eu l'occasion de voir (planet, zyxell), ce sont tous des firmwares dual-stack qui conservent toutes les fonctions habituelles en v4 et ajoutent le minimum vital pour le support v6. Tous intègrent DHCP pour le v4 et l'autoconfiguration sateless (http://www.bortzmeyer.org/4862.html) pour le v6. Le DHCP v6 n'est pas proposé actuellement. Principal problème : ces CPE embarquent généralement un relay DNS qui ne répond qu'en v4, l'annonce du service de résolution par RA(http://www.bortzmeyer.org/5006.html) n'est pas proposé. On est loin de pouvoir les déployer en l'état, surtout pour un fonctionnement v6 only. Les mécanismes de transition ne sont pas intégrés et les équipes consultées (planet) n'y travailleront pas, laissant aux ISP un SDK pour rebuilder le firmware à leur sauce. Bien entendu, ces fabricants de CPE low cost ($50 à $120) ne sont pas représentatifs, mais leurs produits ne sont pas, en l'état, prêts pour un déploiement v6. Petite question en passant : est il envisagé que la résolution DNS inverse pour le préfixe de chaque abonné soit déléguée au CPE routant ce préfixe ? Ca me semblerait pertinant pour assurer la cohésion des hostname entre le LAN et le WAN... -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
