{"id":10,"date":"2007-03-03T13:10:33","date_gmt":"2007-03-03T12:10:33","guid":{"rendered":"http:\/\/wp1.fredptitgars.net\/index.php\/2007\/03\/03\/ipv6\/"},"modified":"2007-03-03T13:10:33","modified_gmt":"2007-03-03T12:10:33","slug":"ipv6","status":"publish","type":"post","link":"https:\/\/fredptitgars.ovh\/?p=10","title":{"rendered":"IPV6"},"content":{"rendered":"

Introduction:<\/h2>\n

Pour communiquer entre 2 ordinateurs il est n\u00e9cessaire que chacun des ordinateur poss\u00e8de une adresse IP (Internet Protocole) en version 4 actuellement (IPV4). Une adresse IPV4 se pr\u00e9sente sous la forme a.b.c.d (ie. 193.252.150.140) – 4 nombres compris entre 0 et 255, separ\u00e9s par des points ces 4 nombres sont encod\u00e9s sur une adresse 32 bits (unit\u00e9 de mesure en informatique repr\u00e9santant 0 ou 1, syst\u00e8me binaire). Ce qui repr\u00e9snte 232 Adresses.
\n
IPv4 a \u00e9t\u00e9 con\u00e7u il y a d\u00e9j\u00e0 un certain de temps (\u00e0 partir de janvier 1980), et, d\u00e8s le d\u00e9but, il y a eu de nombreuses demandes pour accro\u00eetre la quantit\u00e9 d’adresses disponible et augmenter les capacit\u00e9s. Du faite du nombre de demandent, actuellement on arrive en p\u00e9nurie d’adresse.
\n
C’est principalement en raison de cette p\u00e9nurie, mais \u00e9galement pour r\u00e9soudre quelques-uns des probl\u00e8mes r\u00e9v\u00e9l\u00e9s par l’utilisation \u00e0 vaste \u00e9chelle d’IPv4, qu’a commenc\u00e9 en 1995 la transition vers Ipv6 (Internet Protocol Version 6), la version 5 ayant d\u00e9j\u00e0 \u00e9t\u00e9 attribu\u00e9e \u00e0 un protocole exp\u00e9rimental. Parmi les nouveaut\u00e9s essentielles, on peut citer :
\n– l’augmentation de 232 \u00e0 2128 du nombre d’adresses disponibles ;
\n– des m\u00e9canismes de configuration et de renum\u00e9rotation automatique ;
\n– la simplification des en-t\u00eates de paquets, qui facilite notamment le routage. <\/p>\n

1 L’adressage<\/h2>\n

Une adresse IPv6 est un mot de 128 bits. La taille d’une adresse IPv6 est le quadruple de celle d’une adresse IPv4. Ce qui correspond \u00e0 plusieurs milliers d’adresses au m\u00b2 de surface terrestre.<\/p>\n

1.1 Structuration des adresses et agr\u00e9gation<\/strong>
\n
Un des probl\u00e8mes majeurs d’IPv4 est la croissance incontr\u00f4l\u00e9e des tables de routage. Ce ph\u00e9nom\u00e8ne est d\u00fb \u00e0 une mauvaise agr\u00e9gation des adresses dans les tables. Il faudrait \u00eatre capable de router des ensembles de r\u00e9seaux identifi\u00e9s par un seul descripteur. Les adresses IPv4 sont trop courtes pour permettre une bonne structuration, et il faut surtout assumer le co\u00fbt du pass\u00e9 avec les adresses d\u00e9j\u00e0 allou\u00e9es.
\n
Attribuer une adresse \u00e0 un \u00e9quipement est un processus complexe, bas\u00e9 sur un compromis entre la facilit\u00e9 d’attribution et la facilit\u00e9 de gestion. Id\u00e9alement, pour minimiser la taille de routage, le r\u00e9seau devrait avoir une topologie en arbre, cela rendrait l’adressage hi\u00e9rarchique tr\u00e8s efficace. Dans la r\u00e9alit\u00e9 pour des raisons \u00e9conomiques, techniques, g\u00e9ographiques ou de performances, le r\u00e9seau est beaucoup plus complexe
\n
En 2000, la progression lin\u00e9aire de cette table a sembl\u00e9 compromise du fait :
\n– de la baisse du co\u00fbt des liaisons longues distances, permettant une multi-domiciliation des sites pour des raisons de fiabilit\u00e9 , de performances,
\n– le manque d’adresses IPv4 qui force les op\u00e9rateurs \u00e0 allouer des pr\u00e9fixes de plus en plus long.
\n
Depuis, les op\u00e9rateurs ont fortement aggr\u00e9g\u00e9 pour revenir \u00e0 une progression lin\u00e9aire de la table, et la gestion des tables de routage dans le coeur du r\u00e9seau s’en trouve am\u00e9lior\u00e9e.
\n
Si un plan d’adressage hi\u00e9rarchique semble actuellement le plus adapt\u00e9, d’autres r\u00e8gles de num\u00e9rotation pourraient \u00eatre utilis\u00e9es dans le futur, comme par exemple, les coordonn\u00e9es g\u00e9ographiques de l’\u00e9quipement. Ces techniques ne sont actuellement utilis\u00e9es que dans quelques laboratoires de recherche, mais il reste assez de place dans l’espace d’adressage pour prendre en compte ces nouveaux types de r\u00e9seaux si un jour ils se g\u00e9n\u00e9ralisent.
\n
Le choix d’un plan d’adressage a fait l’objet de nombreux d\u00e9bats \u00e0 l’IETF. Il a \u00e9t\u00e9 beaucoup plus difficile \u00e0 d\u00e9finir que le format du paquet IPv6 pr\u00e9sent\u00e9 au chapitre suivant. Plusieurs plans ont \u00e9t\u00e9 propos\u00e9s puis abandonn\u00e9s. <\/p>\n

1.2 Plans d’adressage<\/strong><\/p>\n

Dur\u00e9e de vie des adresses<\/em>
\n
IPv6 g\u00e9n\u00e9ralisant le plan d’adressage CIDR 1, les pr\u00e9fixes restent dans tous les cas la propri\u00e9t\u00e9 des op\u00e9rateurs. Il ne peuvent plus \u00eatre attribu\u00e9s \u00ab\u00a0\u00e0 vie\u00a0\u00bb aux \u00e9quipements. Pour faciliter la renum\u00e9rotation d’une machine l’attribution d’une adresse \u00e0 une interface est faite temporairement, les adresses IPv6 ne sont pas donn\u00e9es mais pr\u00eat\u00e9es. Une dur\u00e9e de vie est associ\u00e9e \u00e0 l’adresse qui indique le temps pendant lequel l’adresse appartient \u00e0 l’interface. La valeur par d\u00e9faut de la dur\u00e9e de vie d’une adresse est de 30 jours, mais cette dur\u00e9e peut \u00eatre prolong\u00e9e, ou port\u00e9e \u00e0 l’infini. L’adresse lien-local a une dur\u00e9e de vie illimit\u00e9e.
\n
La renum\u00e9rotation d’une interface d’une machine consiste \u00e0 passer d’une adresse \u00e0 une autre. Lors d’une renum\u00e9rotation, il n’est pas souhaitable de changer brusquement d’adresse, sinon toutes les communications TCP, qui l’utilisent comme identificateur de connexion, seraient imm\u00e9diatement coup\u00e9es. Ceci entra\u00eenerait des perturbations importantes au niveau des applications.
\n
Pour faciliter cette transition, un m\u00e9canisme d’obsolescence est donc mis en place pour invalider progressivement une adresse. Ce m\u00e9canisme s’appuie sur la capacit\u00e9 d’affectation de plusieurs adresses valides \u00e0 une m\u00eame interface.<\/p>\n

Notation<\/em>
\n
La repr\u00e9sentation textuelle d’une adresse IPv6 se fait en d\u00e9coupant le mot de 128 bits de l’adresse en 8 mots de 16 bits s\u00e9par\u00e9s par le caract\u00e8re \u00ab:\u00bb, chacun d’eux \u00e9tant repr\u00e9sent\u00e9 en hexad\u00e9cimal. Par exemple : FEDC:BA98:7654:3210:EDBC:A987:6543:210F
\nNaturellement, pour \u00e9viter toute ambigu\u00eft\u00e9, l’abr\u00e9viation \u00ab::\u00bb ne peut appara\u00eetre qu’une fois au plus dans une adresse. <\/p>\n

Type des adresses<\/em>
\n
IPv6 reconna\u00eet trois types d’adresses : unicast, multicast et anycast.
\n
Le premier de ces types, le type unicast, est le plus simple. Une adresse de ce type d\u00e9signe une interface unique. Un paquet envoy\u00e9 \u00e0 une telle adresse, sera donc remis \u00e0 l’interface ainsi identifi\u00e9e.
\n
Une adresse de type multicast d\u00e9signe un groupe d’interfaces qui en g\u00e9n\u00e9ral appartiennent \u00e0 des noeuds diff\u00e9rents pouvant \u00eatre situ\u00e9s n’importe o\u00f9 dans l’Internet. Lorsqu’un paquet a pour destination une adresse de type multicast, il est achemin\u00e9 par le r\u00e9seau \u00e0 toutes les interfaces membres de ce groupe.
\n
Le dernier type, anycast, est une officialisation de propositions faites pour IPv4. Comme dans le cas du multicast, une adresse de type anycast d\u00e9signe un groupe d’interfaces, la diff\u00e9rence \u00e9tant que lorsqu’un paquet a pour destination une telle adresse, il est achemin\u00e9 \u00e0 un des \u00e9l\u00e9ments du groupe et non pas \u00e0 tous.<\/p>\n

Adressage global : plan d’adressage agr\u00e9g\u00e9<\/em>
\n
Ce plan pr\u00e9cise la structure d’adressage IPv6 en pr\u00e9cisant les tailles de chacun des blocs. Une adresse int\u00e8gre trois niveaux de hi\u00e9rarchie :
\n– Une topologie publique cod\u00e9 sur 48 bits, allou\u00e9e par le fournisseur d’acc\u00e8s;
\n– Une topologie de site cod\u00e9 sur 16 bits. Ce champ permet de coder les num\u00e9ros de sous r\u00e9seau du site;
\n– Un identifiant d’interface(64 bits) distinguant les diff\u00e9rentes machines sur le lien.<\/p>\n

\"plan_adress.png\"<\/p>\n

1.3 Identifiant d’interface<\/strong>
\n
Les types d’adresses global ou lien-local utilisent un identifiant sur 64 bits pour d\u00e9signer une interface connect\u00e9e sur un lien. Cette longueur b\u00e9n\u00e9ficie d’un fort consensus car elle permet de garantir facilement une unicit\u00e9 sur le lien et par cons\u00e9quent de faciliter l’auto-configuration des \u00e9quipements.
\n
Plusieurs techniques ont \u00e9t\u00e9 \u00e9labor\u00e9es. La plus r\u00e9pandue est bas\u00e9e sur l’utilisation d’une valeur unique par construction comme l’adresse MAC de la machine. Mais l’on peut \u00e9galement choisir une valeur al\u00e9atoire pour garantir plus de confidentialit\u00e9 ou au contraire la d\u00e9river d’une cl\u00e9 publique pour mieux authentifier l’\u00e9m\u00e9tteur du message. La taille de 64 bits permet de r\u00e9duire \u00e0 une valeur proche de z\u00e9ro la probabilit\u00e9 de conflits. Enfin dans certains cas l’affectation manuelle de cette valeur peut se justifier.<\/p>\n

2 Ipv6 le datagramme<\/h2>\n

Hormis la modification de la taille des adresses, ce qui conduit \u00e0 une taille d’en-t\u00eate de 40 octets, le protocole IP a subi un toilettage reprenant l’exp\u00e9rience acquise au fil des ans avec IPv4. Le format des en-t\u00eates IPv6 est simplifi\u00e9 et permet aux routeurs de meilleures performances dans leurs traitements :
\n– L’en-t\u00eate ne contient plus le champ checksum, qui devait \u00eatre ajust\u00e9 par chaque routeur en raison de la d\u00e9cr\u00e9mentation du champ dur\u00e9e de vie. Par contre, pour \u00e9viter qu’un paquet dont le contenu est erron\u00e9 ne se glisse dans une autre communication, tous les protocoles de niveau sup\u00e9rieur doivent mettre en \u0153uvre un m\u00e9canisme de checksum de bout en bout incluant un pseudo-en-t\u00eate qui prend en compte les adresses source et destination. Le checksum d’UDP, facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le checksum int\u00e8gre le pseudo-en-t\u00eate.
\n– La taille des en-t\u00eates est fixe. Le routeur peut facilement d\u00e9terminer o\u00f9 commence la zone de donn\u00e9es utiles.
\n– Les options ont \u00e9t\u00e9 retir\u00e9es de l’en-t\u00eate et remplac\u00e9es par de nouveaux en-t\u00eates appel\u00e9s extensions qui peuvent \u00eatre facilement ignor\u00e9es par les routeurs interm\u00e9diaires.
\n– Les champs sont align\u00e9s sur des mots de 64 bits, ce qui optimise leur traitement, surtout avec les nouvelles architectures \u00e0 64 bits.
\n– La taille minimale des MTU : Maximum Transmission Unit est de 1 280 octets. Le choix de 1 280 comme MTU minimal en IPv6 permet le tunnelage de paquets IPv6. En effet, la taille de 1 500 octets est g\u00e9n\u00e9ralement admise car elle correspond \u00e0 la valeur impos\u00e9e par Ethernet. La majorit\u00e9 des autres r\u00e9seaux offrent une taille sup\u00e9rieure. La valeur de 576 octets retenue pour IPv4 permettait de prendre en compte des r\u00e9seaux comme Appletalk. Pour ces r\u00e9seaux, une couche d’adaptation devra \u00eatre mise en oeuvre pour pouvoir transporter les paquets IPv6.
\n– La fonction de fragmentation a \u00e9t\u00e9 retir\u00e9e des routeurs. Les champs qui s’y reportent ont \u00e9t\u00e9 supprim\u00e9s. Normalement les algorithmes de d\u00e9couverte du PMTU (Path MTU) \u00e9vitent d’avoir recours \u00e0 la fragmentation. Si celle-ci s’av\u00e8re n\u00e9cessaire, une extension est pr\u00e9vue.
\n
Format d’un datagramme Ipv6<\/em><\/p>\n

\"datagram_ipv6.png\"<\/p>\n

Version<\/em> <\/p>\n

Le champ version est le seul champ qui occupe la m\u00eame place dans le paquet IPv6 et dans le paquet IPv4. Sa valeur est 6. <\/p>\n

Classe de trafic<\/em>
\n
Le champ classe de trafic est aussi appel\u00e9 dans les paquets IPv4 octet DiffServ (DS), il prend la place du champ ToS, initialement d\u00e9fini dans la sp\u00e9cification d’IPv4. Le champ DS est d\u00e9coup\u00e9 en deux parties. Le sous-champ DSCP (DiffServ Code Point) contient les valeurs des diff\u00e9rents comportements (priorit\u00e9 du paquet,. Les deux derniers bits du champ sont actuellement non utilis\u00e9s, mais devraient servir aux routeurs pour indiquer un risque de congestion.<\/p>\n

\"class_traffic.png\"<\/p>\n

Pour l’instant deux types de comportement sont standardis\u00e9s :
\n– Assured Forwarding : Ce comportement d\u00e9finit quatre classes de services et trois priorit\u00e9s suivant que l’utilisateur respecte son contrat, le d\u00e9passe l\u00e9g\u00e8rement ou est largement en dehors. Les classes sont donc choisies par l’utilisateur et restent les m\u00eames tout au long du trajet dans le r\u00e9seau. La priorit\u00e9, par contre, peut \u00eatre modifi\u00e9e dans le r\u00e9seau par les op\u00e9rateurs en fonction du respect ou non des contrats.
\n– Explicit Forwarding : Ce comportement est comparable \u00e0 un circuit \u00e0 d\u00e9bit constant \u00e9tabli dans le r\u00e9seau. Le trafic est mis en forme \u00e0 l’entr\u00e9e du r\u00e9seau, en retardant l’\u00e9mission des paquets qui sont hors contrat. <\/p>\n

Identificateur de flux<\/em>
\n
Ce champ contient un num\u00e9ro unique choisi par la source, qui a pour but de faciliter le travail des routeurs et la mise en oeuvre des fonctions de qualit\u00e9 de service <\/p>\n

Longueur des donn\u00e9es utiles<\/em>
\n
Contrairement \u00e0 IPv4, ce champ, sur deux octets, ne contient que la taille des donn\u00e9es utiles, sans prendre en compte la longueur de l’en-t\u00eate. Pour des paquets dont la taille des donn\u00e9es serait sup\u00e9rieure \u00e0 65 535 ce champ vaut 0 et l’option jumbogramme de l’extension de \u00ab\u00a0proche-en-proche\u00a0\u00bb est utilis\u00e9e. Cette option est utilis\u00e9e quand le champ longueur des donn\u00e9es du paquet IPv6 n’est pas suffisant pour coder la taille du paquet. Cette option est essentiellement pr\u00e9vue pour la transmission \u00e0 grand d\u00e9bit entre deux \u00e9quipements. Si l’option jumbogramme est utilis\u00e9e, le champ longueur des donn\u00e9es utiles dans l’en-t\u00eate IPv6 vaut 0. Noter que le type commence par la s\u00e9quence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d’en informer la source.<\/p>\n

En-t\u00eate suivant<\/em>
\n
Ce champ a une fonction similaire au champ protocole du paquet IPv4. Il identifie le prochain en-t\u00eate. Il peut s’agir d’un protocole (de niveau sup\u00e9rieur ICMP, UDP, TCP…) ou de la d\u00e9signation d’extensions (0: Proche en proche, 43: routage, 44: Fragmentation,…). <\/p>\n

Nombre de sauts<\/em>
\n
Il est d\u00e9cr\u00e9ment\u00e9 \u00e0 chaque noeud travers\u00e9. Un datagramme retransmis par un routeur est rejet\u00e9 avec l’\u00e9mission d’un message d’erreur ICMPv6 vers la source si la valeur apr\u00e8s d\u00e9cr\u00e9mentation atteint 0. <\/p>\n

2.1 Les extensions<\/strong>
\n
Les extensions d’IPv6 peuvent \u00eatre vues comme un prolongement de l’encapsulation d’IP dans IP. \u00c0 part l’extension de proche-en-proche trait\u00e9e par tous les routeurs interm\u00e9diaires, les autres extensions ne sont prises en compte que par les \u00e9quipements destinataires du paquet.
\n
Une extension a une longueur multiple de 8 octets. Elle commence par un champ en-t\u00eate suivant d’un octet qui d\u00e9finit le type de donn\u00e9es qui suit l’extension : une autre extension ou un protocole de niveau 4. Pour les extensions \u00e0 longueur variable, l’octet suivant contient la longueur de l’extension en mots de 8 octets, le premier n’\u00e9tant pas compt\u00e9 (une extension de 16 octets a un champ longueur de 1).
\n
L’extention de proche en proche est d\u00e9compos\u00e9 en quatres option:
\n– Pad1 (type 0). Cette option est utilis\u00e9e pour introduire un octet de bourrage.
\n– Padn (type 1). Cette option est utilis\u00e9 plus de 2 octets de bourrage.
\n– Jumbogramme. Cette option est utilis\u00e9e quand le champ longueur des donn\u00e9es du paquet IPv6 n’est pas suffisant pour coder la taille du paquet. Cette option est essentiellement pr\u00e9vue pour la transmission \u00e0 grand d\u00e9bit entre deux \u00e9quipements.
\n– L’option Router Alert demande \u00e0 un routeur d’examiner le contenu des donn\u00e9es qu’il relaie (Router Alert existe \u00e9galement en IPv4). En principe, le processus de relayage (recopier le paquet sur une interface de sortie en fonction de l’adresse destination et des tables de routage) doit \u00eatre le plus rapide possible. Mais pour des protocoles comme la gestion des groupes de multicast avec MLD (Multicast Listener Discovery) ou la signalisation des flux avec RSVP, tous les routeurs interm\u00e9diaires doivent tenir compte des donn\u00e9es.
\n
L’extention Destination, dont le format est identique \u00e0 l’extension de proche-en-proche, contient des options qui sont trait\u00e9es par l’\u00e9quipement destinataire. Pour l’instant, la seule utilit\u00e9 concerne le tunnelage dans des paquets IPv6. Cette option permet de limiter le niveau d’encapsulation dans des tunnels des paquets Ipv6.<\/p>\n

L’extention Routage permet d’imposer \u00e0 un paquet une route diff\u00e9rente de celle offerte par les politiques de routage pr\u00e9sentes sur le r\u00e9seau.<\/p>\n

L’extention Fragmentation permet de d\u00e9couper l’information \u00e0 transmettre en fragment.En IPV6, la fragmentation se fait chez l ’emmetteur, et le r\u00e9assemblage chez le rec\u00e9pteur.<\/p>\n

L’extention de s\u00e9curit\u00e9 par autentification AH (Authentification Header) et confidentialit\u00e9 ESP (Encapsulating Security Payload) permettent de prot\u00e9ger les communications pass\u00e9s sur les r\u00e9seaux Ipv6 en assurant les services de confidentialit\u00e9, authentification et d’ int\u00e9grit\u00e9.<\/p>\n

2.2 Checksum au niveau transport<\/strong>
\n
Parmi les diff\u00e9rences existant entre les datagrammes IPv4 et IPv6, il y a la disparition du checksum dans les en-t\u00eates IP <\/p>\n

3 ICMPv6<\/h2>\n

Le protocole de contr\u00f4le d’IP a \u00e9t\u00e9 revu. Dans IPv4, ICMP (Internet Message Control Protocol) sert \u00e0 la d\u00e9tection d’erreurs, au test, \u00e0 la configuration automatique des \u00e9quipements. Ces trois fonctions ont \u00e9t\u00e9 mieux d\u00e9finies dans IPv6. De plus ICMPv6 int\u00e8gre les fonctions de gestion des groupes de multicast (MLD : Multicast Listener Discovery) qui sont effectu\u00e9es par le protocole IGMP (Internet Group Message Protocol) dans IPv4. ICMPv6 reprend aussi les fonctions du protocole ARP utilis\u00e9 par IPv4. <\/p>\n

\"icmpv6.png\"<\/p>\n

Format g\u00e9n\u00e9rique d’un message ICMP
\n
Le protocole se voit attribuer le num\u00e9ro 58.
\n– Le champ type code la nature du message ICMPv6. Les valeurs inf\u00e9rieures \u00e0 127 sont r\u00e9serv\u00e9es aux messages d’erreur. Les autres valeurs r\u00e9serv\u00e9es aux messages d’information.
\n– Le champ code pr\u00e9cise la cause du message ICMPv6.
\n– Le champ checksum permet de v\u00e9rifier l’int\u00e9grit\u00e9 du paquet ICMP.
\n
Les messages ICMPv6 de compte rendu d’erreur contiennent dans la partie donn\u00e9es le paquet IPv6 ayant provoqu\u00e9 l’erreur. Pour \u00e9viter des probl\u00e8mes de fragmentation la longueur du message ICMPv6 est limit\u00e9e \u00e0 1 280 octets et par cons\u00e9quent le contenu du paquet IPv6 peut \u00eatre tronqu\u00e9. <\/p>\n

Conclusion:<\/h2>\n

IPV6 n’est qu’a ses d\u00e9buts, peu d’\u00e9quipements utilisent actuellement ce protocole.Vue l’\u00e9volution d’internet aujourd’hui, il sera n\u00e9cessaire d’y venir, m\u00eame si IPV4 \u00e0 encore de beau et long jour devant lui. Une cohabitation entre IPV4 et IPV6 sera n\u00e9c\u00e9ssaire le temps de la migration.<\/p>\n

livre.point6.net<\/a>
\n
fr.wikipedia.org<\/a>
\n
rfc-editor.org<\/a>
\n
commentcamarche.net<\/a>
\n
abcdrfc.free.fr<\/a>
\n
iana.org<\/a>
\n
eberre.fbone.net<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Introduction: Pour communiquer entre 2 ordinateurs il est n\u00e9cessaire que chacun des ordinateur poss\u00e8de une adresse IP (Internet Protocole) en version 4 actuellement (IPV4). Une adresse IPV4 se pr\u00e9sente sous la forme a.b.c.d (ie. 193.252.150.140) – 4 nombres compris entre 0 et 255, separ\u00e9s par des points ces 4 nombres sont encod\u00e9s sur une adresse […]<\/p>\n","protected":false},"author":2,"featured_media":6,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-10","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-informatique"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/fredptitgars.ovh\/index.php?rest_route=\/wp\/v2\/posts\/10","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fredptitgars.ovh\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fredptitgars.ovh\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/fredptitgars.ovh\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/fredptitgars.ovh\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10"}],"version-history":[{"count":0,"href":"https:\/\/fredptitgars.ovh\/index.php?rest_route=\/wp\/v2\/posts\/10\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/fredptitgars.ovh\/index.php?rest_route=\/"}],"wp:attachment":[{"href":"https:\/\/fredptitgars.ovh\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fredptitgars.ovh\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fredptitgars.ovh\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}