Suport technique et veille technologique
Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Février 2017 -
Le protocole LISP permet d'utiliser
comme identificateur ou comme localisateur aussi bien des adresses
IPv4 qu'IPv6. Pour
rendre les mécanismes de résolution d'identificateur en
localisateur aussi génériques que possibles, ce nouveau
RFC décrit un format d'adresses qui
permet de gérer les deux familles d'adresses (et davantage).
Il existait des méthodes partielles pour représenter ces deux
familles. Par exemple, on peut décider de tout mettre en
IPv6 et de représenter les adresses
IPv4 sous la forme
« IPv4-mapped » (RFC 4291, section 2.5.5.2, par exemple
::ffff:192.0.2.151
). Ou on pourrait, comme
c'est le cas dans les URL, représenter les
adresses sous forme texte en utilisant les
crochets pour distinguer IPv4 et IPv6 (RFC 3986, section 3.2.2, par exemple
https://192.0.2.151/
vs. https://[2001:db8:3f:ae51::78b:ff1]/
). Mais
le groupe de travail à l'IETF a choisi une
solution qui traite les deux familles sur un pied d'égalité, et
est parfaitement générique (elle intégre d'autres
familles que simplement IPv4 et IPv6). La solution finalement documentée dans ce RFC est très
souple et peut servir à bien d'autres que LISP, dès qu'on veut
représenter des requêtes ou réponses d'un système d'annuaire.
À propos de familles, un terme important à retenir est celui
d'AFI (Address Family Identifier). C'est un
nombre identifiant la famille d'adresses utilisée. Il avait été
introduit
dans le RFC 2453 puis précisé dans le RFC 4760, et peut prendre plusieurs
valeurs, stockées dans un
registre à l'IANA (1 pour IPv4, 2 pour IPv6, etc). 0
indique une famille non spécifiée.
Le format de ces adresses LCA (LISP Canonical Address) est décrit dans la section 3 de notre
RFC. L'adresse LCAF commence par l'AFI de LISP (16387) suivi de
divers champs notamment la longueur totale de l'adresse et son
type. Une LCA peut en effet contenir plus que des adresses IP
(type 1). Elle peut aussi servir à transporter des numéros
d'AS (type 3), des coordonnées
géographiques (type 5), etc. La liste des types possibles est
enregistrée à l'IANA. La section 4 explique les différents
types et l'encodage du contenu associé.
Lorsqu'une LCA indique des adresses IP, elle utilise le type
1 : son contenu est une série de couples {AFI, adresse}. Des
adresses IPv4 (AFI 1) et IPv6 (AFI 2) peuvent donc apparaitre dans
cette liste (mais aussi des adresses
MAC, AFI 6, lorsqu'on crée des
VPN de couche 2, ou
bien des noms de
domaine, AFI 16). Ce seront ces LCA qui seront sans doute les plus
utilisées dans les systèmes de correspondance LISP comme
DDT (RFC 8111) ou ALT (RFC 6836).
Pour les numéros d'AS (type 3), la LCA
contient un numéro d'AS, puis un préfixe (IPv4 ou IPv6) affecté à
cet AS. Quant aux coordonnées géographiques (type 5), elles sont
indiquées sous forme de latitude,
longitude et
altitude dans le système
WGS-84. Cela permet, dans une réponse du système de
correspondance LISP, d'indiquer la position physique du réseau du
préfixe encodé dans la LCA. (Attention, le RFC note bien que cela
a des conséquences pour la vie privée.) On
peut aussi stocker des clés cryptographiques (type 11) dans
une LCA (voir RFC 8111 et RFC 8061).
Les mises en œuvre existantes de LISP utilisent déjà les LCA
(mais ne gèrent pas forcément tous les types officiels).
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)