L'interface de programmation "socket" IPv6 - Revision history

Bruno Deniaud: /*
Les structures de données d'adresses
*/

2006-02-27T10:40:58Z

‎<div id="struct">Les structures de données d'adresses</div>

Bruno Deniaud at 10:37, 27 February 2006

2006-02-27T10:37:11Z

Laurent Toutain: /* Les structures de données d'adresses */

2005-12-14T05:55:59Z

‎Les structures de données d'adresses

Laurent Toutain: /* Ce qui a changé */

2005-12-14T05:52:32Z

‎Ce qui a changé

Laurent Toutain: /* Les structures de données d'adresses */

2005-12-14T05:51:32Z

‎Les structures de données d'adresses

Laurent Toutain: /* Les structures de données d'adresses */

2005-12-14T05:51:09Z

‎Les structures de données d'adresses

Laurent Toutain: /* Les structures de données d'adresses */

2005-12-14T05:50:22Z

‎Les structures de données d'adresses

Laurent Toutain at 05:49, 14 December 2005

2005-12-14T05:49:37Z

New page

==Ce qui a changé==

Les changements opérés de façon à intégrer IPv6 concernent les quatre domaines suivants :

* les structures de données d'adresses ;
* l'interface socket ;
* les primitives de conversion entre noms et adresses ;
* les fonctions de conversions d'adresses.

Ces changements ont été minimisés autant que possible de manière à faciliter le portage des applications IPv4 existantes. En outre, et ce point est important, cette nouvelle API doit permettre l'interopérabilité entre machines IPv4 et machines IPv6 grâce au mécanisme de double pile décrit ci-après.

L'API décrite ici est celle utilisée en Solaris, Linux et systèmes *BSD. Elle correspond à celle définie dans le RFC 3493 avec quelques modifications nécessaires pour prendre en compte les dernières évolutions des protocoles sous-jacents. Cette API est explicitement conçue pour fonctionner sur des machines possédant la double pile IPv4 et IPv6 (cf. See Double pile IPv4/IPv6 pour le schéma d'implémentation d'une telle double pile sous UNIX 4.4BSD). Cette API "socket" est celle disponible dans de nombreux environnements de programmation tels que Java, perl, python, ruby, ...

[[image:CS191.gif]]

Une API "avancée", décrite dans le RFC 3542 permet de programmer les échanges réseaux de manière très précise. Elle sera également utilisée mais de manière succinte et essentiellement par le biais de l'exemple [[one_ping6]].

==Les structures de données d'adresses==

Une nouvelle famille d'adresses ayant pour nom <tt>AF_INET6</tt> et dont la valeur peut varier d'une implémentation à l'autre, a été définie (dans <tt>sys/socket.h</tt>). Également, une nouvelle famille de protocoles ayant pour nom <tt>PF_INET6</tt> a été définie (dans <tt>sys/socket.h</tt>). En principe, on doit avoir :

#define PF_INET6 AF_INET6

La structure de données destinée à contenir une adresse IPv6 est définie comme suit (dans <tt>netinet/in.h<tt>) :

struct in6_addr {
uint8_t s6_addr[16];
};

les octets constituant l'adresse étant rangés comme d'habitude dans l'ordre réseau (''network byte order'').

La structure de données IPv6 <tt>struct sockaddr_in6</tt>, est équivalente à la structure <tt>struct sockaddr_in</tt> d'IPv4. Elle est définie comme suit (dans <tt>netinet/in.h</tt>) pour les systèmes dérivés d'UNIX 4.3BSD :

struct sockaddr_in6 {
sa_family_t sin6_family; /* AF_INET6 */
in_port_t sin6_port; /* numéro de port */
uint32_t sin6_flowinfo; /* identificateur de flux */
struct in6_addr sin6_addr; /* adresse IPv6 */
uint32_t sin6_scope_id; /* ensemble d'interfaces correspondant
* à la portée de l'adresse */
};

Il faut noter que cette structure a une longueur de 28 octets, et est donc plus grande que le type générique <tt>struct sockaddr</tt>. Il n'est donc plus possible de réserver une <tt>struct sockaddr</tt> si la valeur à stocker peut être une <tt>struct sockaddr_in6</tt>. Afin de faciliter la tâche des implémenteurs, une nouvelle structure de données, <tt>struct sockaddr_storage</tt>, a été définie. Celle-ci est de taille suffisante afin de pouvoir prendre en compte tous les protocoles supportés et alignée de telle sorte que les conversions de type entre pointeurs vers les structures de données d'adresse des protocoles supportés et pointeurs vers elle-même n'engendrent pas de problèmes d'alignement. Un exemple d'utilisation pourrait être le suivant :

struct sockaddr_storage ss;

struct sockaddr_in *sin = (struct sockaddr_in *) &ss;
struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *) &ss;

Dans la version 4.4 d'UNIX BSD, la longueur du champ <tt>sin6_family</tt> est passée de 2 octets à 1 octet. L'octet ainsi récupéré contient la taille de la structure <tt>sockaddr_in6</tt> et sert à effectuer correctement la conversion de type vers la structure de données générique <tt>sockaddr</tt> utilisée par bon nombre de primitives de l'interface socket.

La macro-définition <tt>SIN6_LEN</tt>, présente dans toute implémentation 4.4BSD, permet alors de distinguer les versions. Les autres champs restant inchangés, cette structure est presque identique à celle de la précédente version :

#define SIN6_LEN

struct sockaddr_in6 {
u_int8_t sin6_len; /* la longueur de cette structure */
sa_family_t sin6_family; /* AF_INET6 */
in_port_t sin6_port; /* numéro de port */
uint32_t sin6_flowinfo; /* identificateur de flux */
struct in6_addr sin6_addr; /* adresse IPv6 */
uint32_t sin6_scope_id; /* ensemble d'interfaces correspondant
* à la portée de l'adresse */
};

Si le champ <tt>sin6_len</tt> existe (ce qui est testable par le fait que le symbole <tt>SIN6_LEN</tt> est défini), il doit être initialisé par la taille de la structure <tt>sockaddr_in6</tt>.

On notera la présence de deux nouveaux champs (ils n'ont pas d'équivalents dans la structure <tt>sockaddr_in</tt>) dans la structure de données <tt>sockaddr_in6<§tt>, les champs <tt>sin6_flowinfo</tt> et <tt>sin6_scope_id</tt>. Le premier, en réalité structuré, est décrit dans le RFC 2460 et [[Identificateur de flux]]. Le second désigne un ensemble d'interfaces en adéquation avec la portée de l'adresse contenue dans le champ <tt>sin6_addr</tt>. Par exemple, si l'adresse en question est de type [Lien local|lien local]], le champ <tt>sin6_scope_id</tt> devrait être un index d'interface.

@@ Line 67: / Line 67: @@
 Si le champ <tt>sin6_len</tt> existe (ce qui est testable par le fait que le symbole <tt>SIN6_LEN</tt> est défini), il doit être initialisé par la taille de la structure <tt>sockaddr_in6</tt>.
-On notera la présence de deux nouveaux champs (ils n'ont pas d'équivalents dans la structure <tt>sockaddr_in</tt>) dans la structure de données <tt>sockaddr_in6<§tt>, les champs <tt>sin6_flowinfo</tt> et <tt>sin6_scope_id</tt>. Le premier, en réalité structuré, est décrit dans le RFC 2460 et [[Identificateur de flux]]. Le second désigne un ensemble d'interfaces en adéquation avec la portée de l'adresse contenue dans le champ <tt>sin6_addr</tt>. Par exemple, si l'adresse en question est de type [[Lien-local|lien local]], le champ <tt>sin6_scope_id</tt> devrait être un index d'interface.
+On notera la présence de deux nouveaux champs (ils n'ont pas d'équivalents dans la structure <tt>sockaddr_in</tt>) dans la structure de données <tt>sockaddr_in6</tt>, les champs <tt>sin6_flowinfo</tt> et <tt>sin6_scope_id</tt>. Le premier, en réalité structuré, est décrit dans le RFC 2460 et [[Identificateur de flux]]. Le second désigne un ensemble d'interfaces en adéquation avec la portée de l'adresse contenue dans le champ <tt>sin6_addr</tt>. Par exemple, si l'adresse en question est de type [[Lien-local|lien local]], le champ <tt>sin6_scope_id</tt> devrait être un index d'interface.
 {{suivi| Programmation d'applications | Programmation d'applications | L'interface socket | L'interface socket }}

← Older revision		Revision as of 10:37, 27 February 2006
Line 1:		Line 1:
		+	{{suivi\| Programmation d'applications \| Programmation d'applications \| L'interface socket \| L'interface socket }}
	==<div id="change">Ce qui a changé</div>==		==<div id="change">Ce qui a changé</div>==

Line 67:		Line 68:

	On notera la présence de deux nouveaux champs (ils n'ont pas d'équivalents dans la structure <tt>sockaddr_in</tt>) dans la structure de données <tt>sockaddr_in6<§tt>, les champs <tt>sin6_flowinfo</tt> et <tt>sin6_scope_id</tt>. Le premier, en réalité structuré, est décrit dans le RFC 2460 et [[Identificateur de flux]]. Le second désigne un ensemble d'interfaces en adéquation avec la portée de l'adresse contenue dans le champ <tt>sin6_addr</tt>. Par exemple, si l'adresse en question est de type [[Lien-local\|lien local]], le champ <tt>sin6_scope_id</tt> devrait être un index d'interface.		On notera la présence de deux nouveaux champs (ils n'ont pas d'équivalents dans la structure <tt>sockaddr_in</tt>) dans la structure de données <tt>sockaddr_in6<§tt>, les champs <tt>sin6_flowinfo</tt> et <tt>sin6_scope_id</tt>. Le premier, en réalité structuré, est décrit dans le RFC 2460 et [[Identificateur de flux]]. Le second désigne un ensemble d'interfaces en adéquation avec la portée de l'adresse contenue dans le champ <tt>sin6_addr</tt>. Par exemple, si l'adresse en question est de type [[Lien-local\|lien local]], le champ <tt>sin6_scope_id</tt> devrait être un index d'interface.
		+	{{suivi\| Programmation d'applications \| Programmation d'applications \| L'interface socket \| L'interface socket }}

← Older revision		Revision as of 05:52, 14 December 2005
Line 1:		Line 1:
−	==Ce qui a changé==	+	==<div id="change">Ce qui a changé</div>==

	Les changements opérés de façon à intégrer IPv6 concernent les quatre domaines suivants :		Les changements opérés de façon à intégrer IPv6 concernent les quatre domaines suivants :

← Older revision		Revision as of 05:51, 14 December 2005
Line 66:		Line 66:
	Si le champ <tt>sin6_len</tt> existe (ce qui est testable par le fait que le symbole <tt>SIN6_LEN</tt> est défini), il doit être initialisé par la taille de la structure <tt>sockaddr_in6</tt>.		Si le champ <tt>sin6_len</tt> existe (ce qui est testable par le fait que le symbole <tt>SIN6_LEN</tt> est défini), il doit être initialisé par la taille de la structure <tt>sockaddr_in6</tt>.

−	On notera la présence de deux nouveaux champs (ils n'ont pas d'équivalents dans la structure <tt>sockaddr_in</tt>) dans la structure de données <tt>sockaddr_in6<§tt>, les champs <tt>sin6_flowinfo</tt> et <tt>sin6_scope_id</tt>. Le premier, en réalité structuré, est décrit dans le RFC 2460 et [[Identificateur de flux]]. Le second désigne un ensemble d'interfaces en adéquation avec la portée de l'adresse contenue dans le champ <tt>sin6_addr</tt>. Par exemple, si l'adresse en question est de type [[Lien local\|lien local]], le champ <tt>sin6_scope_id</tt> devrait être un index d'interface.	+	On notera la présence de deux nouveaux champs (ils n'ont pas d'équivalents dans la structure <tt>sockaddr_in</tt>) dans la structure de données <tt>sockaddr_in6<§tt>, les champs <tt>sin6_flowinfo</tt> et <tt>sin6_scope_id</tt>. Le premier, en réalité structuré, est décrit dans le RFC 2460 et [[Identificateur de flux]]. Le second désigne un ensemble d'interfaces en adéquation avec la portée de l'adresse contenue dans le champ <tt>sin6_addr</tt>. Par exemple, si l'adresse en question est de type [[Lien-local\|lien local]], le champ <tt>sin6_scope_id</tt> devrait être un index d'interface.

← Older revision		Revision as of 05:51, 14 December 2005
Line 66:		Line 66:
	Si le champ <tt>sin6_len</tt> existe (ce qui est testable par le fait que le symbole <tt>SIN6_LEN</tt> est défini), il doit être initialisé par la taille de la structure <tt>sockaddr_in6</tt>.		Si le champ <tt>sin6_len</tt> existe (ce qui est testable par le fait que le symbole <tt>SIN6_LEN</tt> est défini), il doit être initialisé par la taille de la structure <tt>sockaddr_in6</tt>.

−	On notera la présence de deux nouveaux champs (ils n'ont pas d'équivalents dans la structure <tt>sockaddr_in</tt>) dans la structure de données <tt>sockaddr_in6<§tt>, les champs <tt>sin6_flowinfo</tt> et <tt>sin6_scope_id</tt>. Le premier, en réalité structuré, est décrit dans le RFC 2460 et [[Identificateur de flux]]. Le second désigne un ensemble d'interfaces en adéquation avec la portée de l'adresse contenue dans le champ <tt>sin6_addr</tt>. Par exemple, si l'adresse en question est de type [Lien local\|lien local]], le champ <tt>sin6_scope_id</tt> devrait être un index d'interface.	+	On notera la présence de deux nouveaux champs (ils n'ont pas d'équivalents dans la structure <tt>sockaddr_in</tt>) dans la structure de données <tt>sockaddr_in6<§tt>, les champs <tt>sin6_flowinfo</tt> et <tt>sin6_scope_id</tt>. Le premier, en réalité structuré, est décrit dans le RFC 2460 et [[Identificateur de flux]]. Le second désigne un ensemble d'interfaces en adéquation avec la portée de l'adresse contenue dans le champ <tt>sin6_addr</tt>. Par exemple, si l'adresse en question est de type [[Lien local\|lien local]], le champ <tt>sin6_scope_id</tt> devrait être un index d'interface.

@@ Line 16: / Line 16: @@
 Une API "avancée", décrite dans le RFC 3542 permet de programmer les échanges réseaux de manière très précise. Elle sera également utilisée mais de manière succinte et essentiellement par le biais de l'exemple [[one_ping6]].
-==Les structures de données d'adresses==
+==<div id="struct">Les structures de données d'adresses</div>==
 Une nouvelle famille d'adresses ayant pour nom <tt>AF_INET6</tt> et dont la valeur peut varier d'une implémentation à l'autre, a été définie (dans <tt>sys/socket.h</tt>). Également, une nouvelle famille de protocoles ayant pour nom <tt>PF_INET6</tt> a été définie (dans <tt>sys/socket.h</tt>). En principe, on doit avoir :

@@ Line 22: / Line 22: @@
   #define PF_INET6 AF_INET6
-La structure de données destinée à contenir une adresse IPv6 est définie comme suit (dans <tt>netinet/in.h<tt>) :
+La structure de données destinée à contenir une adresse IPv6 est définie comme suit (dans <tt>netinet/in.h</tt>) :
   struct in6_addr {

L'interface de programmation "socket" IPv6 - Revision history

Bruno Deniaud: /* Les structures de données d'adresses */

Bruno Deniaud at 10:37, 27 February 2006

Laurent Toutain: /* Les structures de données d'adresses */

Laurent Toutain: /* Ce qui a changé */

Laurent Toutain: /* Les structures de données d'adresses */

Laurent Toutain: /* Les structures de données d'adresses */

Laurent Toutain: /* Les structures de données d'adresses */

Laurent Toutain at 05:49, 14 December 2005

Bruno Deniaud: /*
Les structures de données d'adresses
*/