Ce nouveau RFC
normalise deux étiquettes CBOR pour
représenter des adresses IP
et des préfixes d'adresses.
Le format de données CBOR, normalisé dans
le RFC 8949, a une liste de types prédéfinis
mais on peut en créer d'autres, en étiquetant la donnée avec un
entier qui permettre de savoir comment interpréter la donnée en
question. Notre RFC introduit les étiquettes 52 (pour les
adresses IPv4) et 54 (pour les adresses
IPv6). Ah, pourquoi 52 et 54 ? Je vous laisse
chercher, la solution est à la fin de l'article
La section 3 de notre RFC décrit le format. Pour chaque famille
(IPv4 ou IPv6), il y a trois formats (tous avec la même étiquette) :
- Les adresses à proprement parler, représentées sous forme
d'une byte string CBOR (suite d'octets,
cf. RFC 8949, section 3.1, type majeur 2) et
donc pas sous la forme textuelle (celle avec les points pour IPv4
et les deux-points pour IPv6),
- Les préfixes, représentés par un tableau de deux éléments,
un entier pour la longueur du préfixe et une suite d'octets pour
le préfixe lui-même (les octets nuls à la fin doivent être
omis),
- L'interface, sous forme d'un tableau de deux ou trois
éléments, qui comporte une adresse IP, la longueur du préfixe sur
cette interface et éventuellement un identificateur d'interface
(genre
eth0 sur Linux,
voir la section 6 du RFC 4007 pour IPv6, et
les RFC 4001 et RFC 6991 pour IPv4, mais cela
peut aussi être un entier), identificateur qui est local à la
machine.
La section 5 du RFC contient une description en
CDDL (RFC 8610) de ces données.
J'ai écrit une mise en œuvre en Python de ce RFC, qui renvoie à un client
HTTP son
adresse IP, et le préfixe annoncé dans la DFZ en BGP (en utilisant pour cela les
données du RIS,
via le programme WhichASN). Le
service est accessible à l'adresse
https://www.bortzmeyer.org/apps/addresses-in-cbor,
par exemple :
% curl -s https://www.bortzmeyer.org/apps/addresses-in-cbor > tmp.cbor
Le CBOR est du binaire, on peut regarde avec
le programme read-cbor :
% read-cbor tmp.cbor
Array of 3 items
String of length 165: Your IP address in CBOR [...]
Tag 54
Byte string of length 16
Tag 54
Array of 2 items
Unsigned integer 32
Byte string of length 4
On voit que le service renvoie un tableau CBOR de trois entrées :
- Une chaine de caractères de documentation,
- l'adresse IP (ici, de l'IPv6, d'où l'étiquette 54 et les 16
octets),
- le préfixe routé, sous la forme d'une longueur (ici, 32
bits) et des octets non nuls dudit préfixe (ici, au nombre de
4).
Vu avec le
programme cbor2diag, le même
fichier :
% cbor2diag.rb tmp.cbor
["Your IP address in CBOR, done with Python 3.9.2 [...]",
54(h'200141D0030222000000000000000180'),
54([32, h'200141D0'])]
(Le préfixe du client HTTP était en effet bien
2001:41d0::/32.) Le code source de service est
dans
les sources du moteur de ce
blog, plus précisement en
wsgis/dispatcher.py.
Sinon, la raison du choix des étiquettes est que, en ASCII, 52 est le chiffre 4 et 54 est 6. Les
deux étiquettes sont désormais dans le
registre IANA. À noter que la représentation des adresses IP
en CBOR avait été faite initialement avec les étiquettes 260 et 261,
en utilisant un encodage complètement différent. 260 désignait les
adresses (v4 et v6), 261, les préfixes. (Ces deux étiquettes sont
marquées comme abandonnées, dans le registre
IANA.) Au contraire, dans notre nouveau RFC, l'étiquette
identifie la version d'IP, la distinction entre adresse et préfixe
se faisant par un éventuel entier initial pour indiquer la
longueur.
