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.
- Juin 2017 -
Le RFC 6890 avait créé un registre unique
des préfixes d'adresses
IP « spéciaux ». Ce nouveau RFC
met à jour le RFC 6890, précisant et
corrigeant quelques points.
Un préfixe « spécial » est juste un préfixe
IP dédié à un usage inhabituel, et qui peut
nécessiter un traitement particulier. Ainsi, les préfixes
203.0.113.0/24 et
2001:db8::/32 sont dédiés à la documentation,
aux cours et exemples et, bien que n'étant pas traités
différemment des autres préfixes par les routeurs, ne doivent normalement pas
apparaitre dans un vrai réseau. Le RFC 6890
spécifie les deux registres de préfixes spéciaux, un
pour IPv4 et un
pour IPv6. Mais il y avait une ambiguité dans ce RFC, dans
l'usage du terme « global ». Il n'est pas
évident à traduire en français. Dans le langage courant,
global/globalement, a surtout le sens de « le plus
souvent/généralement », alors que, dans le contexte de l'Internet,
ce serait plutôt dans le sens « valable pour tout point du
globe ». Même en anglais, le
terme est polysémique : il peut signifier que
l'adresse IP est unique au niveau mondial ou bien il peut
signifier que l'adresse est potentiellement joignable
mondialement, et qu'un routeur peut donc faire suivre le paquet en
dehors de son propre domaine. (La joignabilité effective, elle,
dépend évidemment de l'état de BGP.) Le
RFC 4291, dans sa section 2.5.4, n'est pas
plus clair.
Reprenons l'exemple des préfixes de documentation. Dans les trois
préfixes IPv4 de documentation (comme
203.0.113.0/24), les adresses ne sont pas
uniques (chacun les alloue comme il veut et, vu le faible nombre
d'adresses total, il y aura certainement des collisions) et, de
toute façon, n'ont pas de signification en dehors d'un domaine :
cela n'a pas de sens de transmettre des paquets ayant de telles
adresses à ses partenaires. Pour le préfixe de documentation IPv6,
2001:db8::/32, c'est un peu plus compliqué
car les adresses peuvent être quasi-uniques mondialement (si on
prend la précaution de les tirer au sort dans le préfixe) mais, de
toute façon, n'ont pas vocation à être joignables de partout et on
ne transmet donc pas ces paquets à ses voisins.
Bref, notre nouveau RFC choisit d'être plus précis, renommant
l'ancien booléen « global » du RFC 6890 en
« globally reachable ».
La nouvelle définition (section 2) est donc bien « le paquet
ayant cette adresse comme destination peut être transmis par un
routeur à un routeur d'un autre domaine (d'un autre opérateur, en
pratique) ». La colonne Global du registre est donc remplacée par
Globally reachable. Notez qu'il n'y a pas de
colonne « Unicité » (une autre définition possible de
global).
Cela a nécessité quelques changements supplémentaires dans le
registre (toujours section 2), colonne Globally reachable :
- Le préfixe Teredo
2001::/32 passe de False
(les adresses Teredo ne sont pas uniques) à
N/A (Not Applicable) car
la question de la joignabilité mondiale n'a pas vraiment de sens
pour Teredo,
- Les ULA du RFC 4193 restent à False mais avec une
précision en note.
