Merci Rémi, merci Stéphane

[jefsey <[e-mail]>]

Chers Cafeducompères, et Caféducomères,

la réflexion des utilisateurs pilotes portée par l'IUCG puis ALFA 
pour des questions de copyright ISOC, s'est surtout préoccupée 
jusqu'à présent des aspects nommage à notre portée immédiate, et la 
manière dont IDv6 (adressage local IPv6) pouvait ainsi être introduit 
même sous IPv4. Nous avons laissé les aspects IPv6 généraux à la 
sagacité des ingénieurs et opérateurs. Tout en suivant ce qui pouvait 
amener à une utilisation plus sure, plus stable et ainsi plus 
efficace au niveau IP : c'est ce que nous avons appelé "IPP", la 
réflexion étant de considérer (en fonction du temps et des 
contributions) le document de Fernando Gont du CPNI anglais 
(http://tools.ietf.org/html/draft-ietf-opsec-ip-security-04 - pas à 
regarder avant d'avoir un thermos de café à sa disposition).

Comme d'habitude, Stéphane Bortzmeyer ouvre à la compréhension des 
simples utilisateurs que nous sommes (si on le lit de bout en bout) 
un point français clé :
http://www.bortzmeyer.org/fragmentation-ip-1280.html

----

Monsieur Rémi Després, ancien directeur technique de Transpac, tente 
de faire bouger le mammouth IPv6 dans la bonne direction pour qu'il 
devienne compatible avec l'internet tel que ses utilisateurs que nous 
sommes le connaissent. Il a déjà fait bouger Free. Il a déjà réussi à 
publier une RFC, etc. Certains Américains commencent à le surnommer Remiv6.

Si nous comprenons bien Stéphane et si celui-ci comprend bien Rémi, 
et que Louis confirme la stricte équivalence paquet/datagramme de 
Stéphane (mes souvenirs sont que la différence est qu'on sait si l'un 
arrive et pas l'autre) dans le cas discuté, l'idée est de réduire 
tous les datagrammes à 1280 octets pour qu'ils passent partout, ce 
qui semble un objectif louable. Dans ce cas, si je comprends bien le 
flux des contenus échangés via Internet serait indifférent à la 
nature locale ou non du réseau et au protocole IPv4 ou IPv6.

Questions :

1. il y a-t-il un avantage à ce que tous les envois et réception 
d'une architecture d'interface d'_utilisation_de l'Internet et 
d'autres technologies numériques (IUI) s'autolimitent à des 
datagrammes de 1280 octets ? Dans ce cas la transition serait par 
simple pratique et désuétude opérationnelle d'une possibilité 
inefficace sauf cas particulier, relevant d'une BCP (best common 
practice) et pas d'un possible standard (Standard Track) ?

2. dans le calcul que fait Stéphane de la surcharge qui en résulte, 
il ne prend pas en compte la suppression du trafic des datagrammes refoulés.

3. L'utilisation (IUse) a d'autres attentes en fait d'IPv6. Serait-il 
confusant de parler d'IPPv6 (IPPlus) pour une convention d'usage 
d'IPv6 qui prendrait en compte des caractéristiques particulières 
entre interfaces InterPLUS, en rappelant que PLUS signifie (Plugged 
Layers on the User Side) et qu'il est approché dans le cadre de la 
relecture du support de la diversité (linguistique dans le cas des 
IDNs) appliqué par les RFC 5890/95, cette relecture n'impliquant 
aucun changement du code interne de l'Internet ?

La jeune communauté des IUsers ayant diverses préoccupations à 
supporter de cette manière, le support d'IPP est envisagé dans 
l'exploration de l'Interplus, mais n'a pas été engagé à ce jour, la 
priorité étant au développement et à l'expérimentation du ML-DNS.

jfc

PS. Ce mail est envoyé à cafedu.com et wikalfa, copie en français à 
l'IUCG pour montrer que cette discussion est de domaine publique et 
n'est pas soumise au copyright ISOC auquel s'astreint l'IUCG dans le 
cadre de l'IETF.