Re: type d'un champ mysql
On Tue, Jan 13, 2009 at 10:19:21AM +0100,
Mathieu JANIN <mattotop@orange.fr> wrote
a message of 53 lines which said:
> pour récupèrer les machine d'un réseau de classe A,
Mauvaise idée, les classes ayant été supprimées il y a plus de dix
ans.
http://www.bortzmeyer.org/fini-les-classes.html
----------------------------
On voit souvent des administrateurs réseaux parler de « classe B » ou
de « classe C » en se référant à un groupe d'adresses IP. Ces termes
sont dépassés et reflètent une réalité qui a disparu depuis longtemps.
Ils ne devraient plus être employés.
Pour expliquer pourquoi, je dois faire un détour sur la façon dont
fonctionne l'adressage IP, normalisé, pour IP version 4, dans le RFC
791. Les adresses IPv4 faisant 32 bits, ce protocole permet 2^32 soit
plus de quatre milliards d'adresses. Pas question que les routeurs
aient une route vers chacune de ces adresses. Leur mémoire n'y
suffirait pas et, surtout, le rythme de changement serait trop élevé.
On regroupe donc aujourd'hui les adresses contiguës en *préfixes* de
longueur N où N est le nombre de bits qui servent à identifier le
préfixe, les autres bits identifiant la machine. En IPv4 et IPv6, ce
nombre de bits n'est pas fixé par le protocole, il est déterminé par
l'administrateur système. On note un réseau par son préfixe, suivi
d'une barre oblique et de la longueur du préfixe. Par exemple, le
préfixe 192.0.2.128/25 a une longueur N de 25 bits, ces 25 bits valant
11000000 00000000 00000010 10000000, laissant 7 bits pour identifier
une machine sur ce réseau. Si plusieurs routes sont possibles pour une
destination donnée, le routeur prendra la *plus spécifique* (celle dont
N est le plus grand).
A t-on toujours fait comme cela ? Non. Il y a de nombreuses années, les
préfixes étaient de taille fixe, on avait uniquement le choix en des
préfixes de longueur 8, baptisés « classes A », de longueur 16, les
« classes B » et de longueur 24, les « classes C ». Ce système était
très rigide et gaspillait considérablement les adresses (si une classe
C ne suffisait pas, pas possible de prendre un /23, il fallait sauter
directement à une classe B). Il a donc été abandonné au profit de
l'adressage actuel, qui avait été baptisé CIDR pour "Classless
Inter-Domain Routing". "Classless" donc, « sans classe ». Ce nom dit
bien ce qu'il veut dire, les classes ont disparu.
Le premier RFC sur les idées qui mèneront à CIDR a été le RFC 1338 en
juin 1992. Le RFC 1467 en août 1993 faisait le point sur le déploiement
de CIDR. Les RFC 1518 et RFC 1519 en septembre 1993 sont les premier à
décrire CIDR sous sa forme actuelle, pendant que le RFC 1517 décrivait
les motivations et les problèmes que CIDR visait à résoudre. C'est donc
depuis quinze ans que les classes ont disparu ! Révisée, la norme
actuelle est le RFC 4632. Comme on le voit, l'adressage actuel est très
ancien. Il est très inquiétant que des enseignants ignorants donnent
toujours des cours IP où les classes sont citées, sans préciser
qu'elles n'ont qu'un intérêt historique.
Les classes se voient encore un peu dans certaines techniques comme le
DNS où les délégations dans in-addr.arpa se font sur des frontières
d'octets. Ce problème a été largement réglé par le RFC 2317.
Pendant les quelques années où la communauté Internet testait la
nouvelle technique, certains termes avaient été utilisés, qui n'ont
plus de raison d'être. C'est ainsi qu'on parlait de "supernetting" pour
désigner l'*agrégation* de plusieurs classes en un préfixe plus général
(cette technique étant la base de CIDR, elle n'a plus besoin d'un nom
spécifique, même s'il faut encore apparemment dire à IOS ip classless
pour qu'il l'accepte). De même, les VLSM ("Variable Length Subnet Mask"
ont été oubliés : le masque du réseau est désormais *toujours* de
longueur variable.
Le successeur d'IPv4, IPv6, est, lui, parti proprement en tenant compte
de l'expérience de son prédécesseur et a toujours été « sans classe ».
> Enfin je prendrais plutot pgsql pour ses fonctionnalités IP, si
> j'avais le choix.
Oui, je ne sais pas pourquoi l'OP a choisi MySQL.
Reply to: