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.
- Septembre 2017 -
Ce très court RFC documente la
réservation du préfixe IPv6
64:ff9b:1::/48, pour les divers mécanismes de
traduction entre IPv6 et IPv4.
L'adressage de ces mécanismes de traduction est décrit dans le
RFC 6052. Il réservait le préfixe
64:ff9b::/96, qui s'est avéré insuffisant et
est désormais complété par notre RFC 8215.
Ouvrez bien l'œil : ces deux préfixes sont différents, même si
leurs quatre premiers octets sont identiques (c'est un problème
fréquent en IPv6 : il peut être difficile de distinguer deux
adresses du premier coup.)
La section 3 de notre RFC expose le problème : depuis la
publication du RFC 6052, plusieurs
mécanismes de traduction IPv4<->IPv6 ont été proposés (par
exemple dans les RFC 6146 et RFC 7915). Ils ne sont pas inconciliables (ils couvrent
parfois des scénarios différents ) et un opérateur peut donc
vouloir en déployer plusieurs à la fois. Le seul préfixe
64:ff9b::/96 ne va alors plus suffire. Il
faut donc un préfixe plus grand, et dont l'usage n'est pas
restreint à une seule technologie de traduction.
Pourquoi 64:ff9b:1::/48, d'ailleurs ? La
section 4 répond à la question. La longueur de 48 bits a été
choisie pour permettre plusieurs mécanismes de traduction, chacun
utilisant un préfixe plus spécifique. Par exemple, si chaque
mécanisme utilise un /64, le préfixe réservé pour les englober
tous devait être un /48, ou plus général (on se limite aux
multiples de 16 bits, car ils permettent que les préfixes se
terminent sur un deux-points, facilitant la
vie de l'administrateur réseaux qui devra les manipuler).
Ensuite, pourquoi cette valeur
64:ff9b:1:: ? Parce qu'elle est proche
(presque adjacente) du
64:ff9b::/96, minimisant la consommation
d'adresses IPv6. (64:ff9a:ffff::/48 est
complètement adjacent, de l'autre côté, mais l'agrégation avec
64:ff9b::/96 en un seul préfixe est beaucoup
moins efficace. Et puis 64:ff9b:1:: est plus
court.)
À part son usage, 64:ff9b:1::/48 est un
préfixe IPv6 normal et les routeurs, ou autres machines qui
manipulent des adresses IPv6, ne doivent pas le traiter
différemment des autres.
Le nouveau préfixe est désormais enregistré dans le registre des adresses IPv6 spéciales
(section 7 de notre RFC).
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 (...)
