Le protocole
Notre RFC crée donc un nouveau type d'enregistrement DNS, nommé
logiquement HIP (numéro
55), qui stocke, en échange d'un
Notre RFC permet de trouver l'identificateur à partir du nom mais pas le localisateur ; les serveurs de rendez-vous sont une solution possible pour cela ; une autre est d'utiliser les traditionnels enregistrements A et AAAA du DNS, le localisateur HIP étant une adresse IP.
Les localisateurs peuvent changer fréquemment alors que le DNS
n'est pas temps-réel et ne change pas instantanément. Si un hôte HIP
veut pouvoir être contacté malgré des changements d'adresse IP
rapides, il vaut peut-être mieux qu'il utilise le système de
rendez-vous du
Curieusement (pour moi), le HIT est donc stocké dans les données DNS, alors que celles-ci n'offrent aucune sécurité au point que le RFC exige en section 4.1 de recalculer le HIT qui vient d'être obtenu dans le DNS.
Le tout ressemble donc aux enregistrements IPSECKEY du
Voici un exemple d'enregistrement HIP tel qu'il apparaitrait dans un
fichier de zone (sections 5 et 6 de notre RFC). On y trouve
l'algorithme cryptographique utilisé (2 = Par contre, je n'ai pas réussi à trouver encore ce genre
d'enregistrement dans la nature.
L'ensemble du RFC est assez court, ce mécanisme d'annuaire qu'est le DNS étant simple et bien connu.
Quels sont les changements depuis le premier RFC, le