Masques de sous réseau

Salut,

On Fri, 19 Nov 2004 18:34:05 +0100, Julien Arlandis <juliendusud@free.fr>
wrote:

Est il possible des masques d'une autre forme que :
111....111000000

De façon générale, non. En pratique, en local sur un réseau isolé, ça
devrait pouvoir marcher, mais je pense que certains équipements refuseront
un masque qui n'ait pas la bonne forme. Dès qu'on sort de là, ça ne marche
pas parce que ça casse complètement la notion de hierarchie de réseaux, de
route la plus spécifique, etc. Bref, tout CIDR.

En fait celà devrait être possible, car sinon pourquoi s'embêter à
écrire le masque réseau sous la forme d'une IP alors qu'un simple nombre
entier (variant de 1 à 24) suffit pour indiquer le nombre de bits de la
partie réseau?

La notation la plus courante de nos jours chez les ingénieurs et
opérateurs réseaux est de la forme <réseau>/<longueur du préfixe> (par
exemple 192.168.1.0/24). Et la longueur du préfixe peut varier de 0 à 32,
pas de 1 à 24 :-)

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Salut,

On Fri, 19 Nov 2004 18:34:05 +0100, Julien Arlandis
<juliendusud@free.fr> wrote:

Est il possible des masques d'une autre forme que :
111....111000000

De façon générale, non. En pratique, en local sur un réseau isolé, ça
devrait pouvoir marcher, mais je pense que certains équipements
refuseront un masque qui n'ait pas la bonne forme. Dès qu'on sort de
là, ça ne marche pas parce que ça casse complètement la notion de
hierarchie de réseaux, de route la plus spécifique, etc. Bref, tout CIDR.

La notion de hiérarchie est une notion insupportable pour l'anarchiste
que je prétend être ;-)
N'existe t-il pas justement des protocoles qui permettraient de router
les paquets sans nécessiter aucune hiérarchie préalable?
Je pense à un protocole dans lequel l'adresse qui identifierait une
machine serait tout simplement un chemin entre moi et la machine que je
cherche à contacter.

Par exemple, considérons le réseau suivant représenté par le graphe
suivant : les lettres majuscules correspondent à des sous-réseaux, un
chemin (traits pointillés) met en évidence l'interconnection de 2 réseaux.

________
| |
Julien---A---B---C---D---E---F---Jacques
|___________|

Dans ce cas, votre identifiant serait du type :
A|B|C|D|E|F|Jacques
ou bien
A|B|D|E|F|Jacques
ou bien
A|B|C|F|Jacques

En fait celà devrait être possible, car sinon pourquoi s'embêter à
écrire le masque réseau sous la forme d'une IP alors qu'un simple
nombre entier (variant de 1 à 32) suffit pour indiquer le nombre de
bits de la partie réseau?

La notation la plus courante de nos jours chez les ingénieurs et
opérateurs réseaux est de la forme <réseau>/<longueur du préfixe> (par
exemple 192.168.1.0/24). Et la longueur du préfixe peut varier de 0 à
32, pas de 1 à 24 :-)

J'ai écrit de 1 à 24? ;-)

On Fri, 19 Nov 2004 19:49:16 +0100, Julien Arlandis <juliendusud@free.fr>
wrote:

La notion de hiérarchie est une notion insupportable pour l'anarchiste
que je prétend être ;-)

Ah ben oui, mais il y a plus de 10 ans on s'est rendu compte que
l'Internet anarchique ne fonctionnerait pas longtemps, alors on l'a
structuré un peu.

N'existe t-il pas justement des protocoles qui permettraient de router
les paquets sans nécessiter aucune hiérarchie préalable?

IP ne requiert pas fondamentalement une hierarchie (il peut très bien y
avoir plusieurs chemins entre deux points, tout ne passe par forcément par
un arbre simple -- en fait loin de là). Mais il y a une hierarchie dans
l'attribution des adresses (qui n'est pas reflétée dans leur routage,
d'ailleurs -- contrairement à ce que tente de faire IPv6 et qui ne colle
pas du tout avec la réalité).

Je pense à un protocole dans lequel l'adresse qui identifierait une
machine serait tout simplement un chemin entre moi et la machine que je
cherche à contacter.

Ce ne serait donc pas une adresse mais un chemin, et elle s'accomoderait
mal d'un problème sur le dit chemin ou d'un changement de topologie.

________
| |
Julien---A---B---C---D---E---F---Jacques
|___________|

Dans ce cas, votre identifiant serait du type :
A|B|C|D|E|F|Jacques
ou bien
A|B|D|E|F|Jacques
ou bien
A|B|C|F|Jacques

Oui mais si l'adresse donnée était (par exemple) la première et que C
tombait en panne, on ne pourrait pas me joindre alors qu'il y a un autre
chemin...

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

On Fri, 19 Nov 2004 19:49:16 +0100, Julien Arlandis
<juliendusud@free.fr> wrote:

La notion de hiérarchie est une notion insupportable pour
l'anarchiste que je prétend être ;-)

Ah ben oui, mais il y a plus de 10 ans on s'est rendu compte que
l'Internet anarchique ne fonctionnerait pas longtemps, alors on l'a
structuré un peu.

Ce n'est dans ce sens que j'entend le mot anarchie, l'anarchie ce n'est
pas l'absence de règles et de structures mais l'absence d'autorité qui
imposerait ses règles et ses structures. D'ailleurs la tendance dans le
développement du logiciel libre c'est plutôt le respect des standards,
contrairement aux systèmes propriétaires qui veulent créer les leurs.
Usenet qui s'appuye sur le protocole de diffusion NNTP présente une
meilleure approche de ce que pourrait être un internet anarchique.
L'intelligence de ce protocole, c'est qu'il ne recquiert aucun contrôle
centralisé, aucune autorité ne peut par exemple contrôler l'ensemble des
articles d'un newsgroup non modéré.

N'existe t-il pas justement des protocoles qui permettraient de
router les paquets sans nécessiter aucune hiérarchie préalable?

IP ne requiert pas fondamentalement une hierarchie (il peut très bien y
avoir plusieurs chemins entre deux points, tout ne passe par forcément
par un arbre simple -- en fait loin de là). Mais il y a une hierarchie
dans l'attribution des adresses (qui n'est pas reflétée dans leur
routage, d'ailleurs -- contrairement à ce que tente de faire IPv6 et
qui ne colle pas du tout avec la réalité).

L'attribution des IP suit une hiérarchie mais le routage n'en suit pas
vraiment, à chaque interconnection de 2 réseaux, il y a brisure de la
hiérarchie. C'est ce qui fait d'internet une toile et non un arbre.
Du coup l'attribution hiérarchisée des adresses IP n'est plus vraiment
justifiée.

Je pense à un protocole dans lequel l'adresse qui identifierait une
machine serait tout simplement un chemin entre moi et la machine que
je cherche à contacter.

Ce ne serait donc pas une adresse mais un chemin, et elle
s'accomoderait mal d'un problème sur le dit chemin ou d'un changement
de topologie.

Le protocole proposé permet juste de gérer le transport d'un paquet vers
un hôte dont on connait le chemin à un instant t, il ne fournit aucune
précision sur la manière dont un hôte va acquérir le chemin d'un autre
hôte. Pour ce faire il faudrait utiliser des sortes de serveurs DNS qui
associeraient le chemin d'un hôte (par rapport au serveur DNS) qu'on
cherche à contacter.
Si par exemple, le chemin de mon DNS est A|B|C|D|mydns et qu'il me
fournit le chemin de google : D|J|K|L|M|google,
je saurai que le chemin que je dois utiliser pour contacter google est :
A|B|C|D|J|K|L|M|google
Dès qu'il y a un changement de topologie, les routeurs concernés
enregistreront leur nouveau chemin sur leur serveur DNS qui pourra ainsi
recréer les nouveaux chemins.
Dans mon exemple, le chemin de google enregistré par mon DNS est
D|J|K|L|M|google, si K disparait, le chemin de L deviendra D|J|L
et le chemin de google deviendra D|J|L|M|google

________
| |
Julien---A---B---C---D---E---F---Jacques
|___________|

Dans ce cas, votre identifiant serait du type :
A|B|C|D|E|F|Jacques
ou bien
A|B|D|E|F|Jacques
ou bien
A|B|C|F|Jacques

Oui mais si l'adresse donnée était (par exemple) la première et que C
tombait en panne, on ne pourrait pas me joindre alors qu'il y a un
autre chemin...

Il suffit de connaitre un autre chemin fonctionnel.
Ce sera le rôle du serveur DNS de fournir d'autres chemin quand un
chemin n'est pas opérationnel.

L'avantage de ce principe c'est qu'un hôte pourrait choisir n'importe
quelle adresse IP de son choix qui l'identifierait au sein d'un réseau,
(la seule restriction étant évidemment que deux hôtes dans un même
réseau n'aient pas la même IP).
Pour contacter un hôte il me suffit d'émettre un datagramme IP en
remplaçant les champs source et destination par le chemin de l'hôte que
je désire contacter. Un chemin étant la liste de tous les routeurs qui
me séparent de l'hôte à contacter suivi de son ip. Pour me répondre,
l'hôte contacté pourra connaitre mon chemin en lisant le chemin à l'envers.

Il manquerait pas grand chose à ipv4 pour le rendre fonctionnel à ce
principe, il suffit juste de rajouter un champ dans le datagramme qui
indiquerait la longueur d'un chemin, le chemin remplacerait les champs
source et destination. Il faudrait également rajouter un champ pour
indiquer au routeur qui reçoit un paquet à transmettre sa position dans
le chemin.

On Fri, 19 Nov 2004 19:49:16 +0100, Julien Arlandis
<juliendusud@free.fr> wrote:

La notion de hiérarchie est une notion insupportable pour
l'anarchiste que je prétend être ;-)

Ah ben oui, mais il y a plus de 10 ans on s'est rendu compte que
l'Internet anarchique ne fonctionnerait pas longtemps, alors on l'a

structuré un peu.


Ce n'est dans ce sens que j'entend le mot anarchie, l'anarchie ce n'est
pas l'absence de règles et de structures mais l'absence d'autorité qui
imposerait ses règles et ses structures. D'ailleurs la tendance dans le
développement du logiciel libre c'est plutôt le respect des standards,
contrairement aux systèmes propriétaires qui veulent créer les leurs.
Usenet qui s'appuye sur le protocole de diffusion NNTP présente une
meilleure approche de ce que pourrait être un internet anarchique.
L'intelligence de ce protocole, c'est qu'il ne recquiert aucun contrôle
centralisé, aucune autorité ne peut par exemple contrôler l'ensemble des
articles d'un newsgroup non modéré.

N'existe t-il pas justement des protocoles qui permettraient de
router les paquets sans nécessiter aucune hiérarchie préalable?

IP ne requiert pas fondamentalement une hierarchie (il peut très bien
y avoir plusieurs chemins entre deux points, tout ne passe par

forcément par un arbre simple -- en fait loin de là). Mais il y a une
hierarchie dans l'attribution des adresses (qui n'est pas reflétée dans
leur routage, d'ailleurs -- contrairement à ce que tente de faire IPv6
et qui ne colle pas du tout avec la réalité).


L'attribution des IP suit une hiérarchie mais le routage n'en suit pas
vraiment, à chaque interconnection de 2 réseaux, il y a brisure de la
hiérarchie. C'est ce qui fait d'internet une toile et non un arbre.
Du coup l'attribution hiérarchisée des adresses IP n'est plus vraiment
justifiée.

Je pense à un protocole dans lequel l'adresse qui identifierait une
machine serait tout simplement un chemin entre moi et la machine que

je cherche à contacter.

Ce ne serait donc pas une adresse mais un chemin, et elle
s'accomoderait mal d'un problème sur le dit chemin ou d'un changement

de topologie.


Le protocole proposé permet juste de gérer le transport d'un paquet vers
un hôte dont on connait le chemin à un instant t, il ne fournit aucune
précision sur la manière dont un hôte va acquérir le chemin d'un autre
hôte. Pour ce faire il faudrait utiliser des sortes de serveurs DNS qui
associeraient le chemin d'un hôte (par rapport au serveur DNS) qu'on
cherche à contacter.
Si par exemple, le chemin de mon DNS est A|B|C|D|mydns et qu'il me
fournit le chemin de google : D|J|K|L|M|google,
je saurai que le chemin que je dois utiliser pour contacter google est :
A|B|C|D|J|K|L|M|google
Dès qu'il y a un changement de topologie, les routeurs concernés
enregistreront leur nouveau chemin sur leur serveur DNS qui pourra ainsi
recréer les nouveaux chemins.
Dans mon exemple, le chemin de google enregistré par mon DNS est
D|J|K|L|M|google, si K disparait, le chemin de L deviendra D|J|L
et le chemin de google deviendra D|J|L|M|google

________
| |
Julien---A---B---C---D---E---F---Jacques
|___________|

Dans ce cas, votre identifiant serait du type :
A|B|C|D|E|F|Jacques
ou bien
A|B|D|E|F|Jacques
ou bien
A|B|C|F|Jacques

Oui mais si l'adresse donnée était (par exemple) la première et que C
tombait en panne, on ne pourrait pas me joindre alors qu'il y a un

autre chemin...


Il suffit de connaitre un autre chemin fonctionnel.
Ce sera le rôle du serveur DNS de fournir d'autres chemin quand un
chemin n'est pas opérationnel.

L'avantage de ce principe c'est qu'un hôte pourrait choisir n'importe
quelle adresse IP de son choix qui l'identifierait au sein d'un réseau,
(la seule restriction étant évidemment que deux hôtes dans un même
réseau n'aient pas la même IP).
Pour contacter un hôte il me suffit d'émettre un datagramme IP en
remplaçant les champs source et destination par le chemin de l'hôte que
je désire contacter. Un chemin étant la liste de tous les routeurs qui
me séparent de l'hôte à contacter suivi de son ip. Pour me répondre,
l'hôte contacté pourra connaitre mon chemin en lisant le chemin à l'envers.

Il manquerait pas grand chose à ipv4 pour le rendre fonctionnel à ce
principe, il suffit juste de rajouter un champ dans le datagramme qui
indiquerait la longueur d'un chemin, le chemin remplacerait les champs
source et destination. Il faudrait également rajouter un champ pour
indiquer au routeur qui reçoit un paquet à transmettre sa position dans
le chemin.

Salut,

Julien Arlandis wrote:

L'attribution des IP suit une hiérarchie mais le routage n'en suit pas
vraiment, à chaque interconnection de 2 réseaux, il y a brisure de la
hiérarchie. C'est ce qui fait d'internet une toile et non un arbre.
Du coup l'attribution hiérarchisée des adresses IP n'est plus vraiment
justifiée.

Si, elle a pour but d'éviter l'explosion de la taille des tables de
routages.

Je pense à un protocole dans lequel l'adresse qui identifierait une
machine serait tout simplement un chemin entre moi et la machine que
je cherche à contacter.
[...]

Pour contacter un hôte il me suffit d'émettre un datagramme IP en
remplaçant les champs source et destination par le chemin de l'hôte que
je désire contacter. Un chemin étant la liste de tous les routeurs qui
me séparent de l'hôte à contacter suivi de son ip. Pour me répondre,
l'hôte contacté pourra connaitre mon chemin en lisant le chemin à l'envers.

Attention, le routage ne peut pas toujours être symétrique.

Il manquerait pas grand chose à ipv4 pour le rendre fonctionnel à ce
principe, il suffit juste de rajouter un champ dans le datagramme qui
indiquerait la longueur d'un chemin, le chemin remplacerait les champs
source et destination.

En fait ça ressemble à quelque chose qui existe déjà dans IP mais qui à
ma connaissance n'est pas utilisé : le routage source (source routing).

Salut,

Julien Arlandis wrote:

L'attribution des IP suit une hiérarchie mais le routage n'en suit pas
vraiment, à chaque interconnection de 2 réseaux, il y a brisure de la
hiérarchie. C'est ce qui fait d'internet une toile et non un arbre.
Du coup l'attribution hiérarchisée des adresses IP n'est plus vraiment
justifiée.

Si, elle a pour but d'éviter l'explosion de la taille des tables de
routages.

Il est encore relativement coûteux d'interconnecter les réseaux entre
eux, mais ce sera bientôt un jeu d'enfant en utilisant les canaux
hertziens ou les satellites. Si l'attribution hiérarchisée des adresses
IP a permi d'alléger les tables de routage c'est parce que
l'interconnection des réseaux a longtemps été soumise à des contraintes
géographiques mais qui sont appelées à disparaitre dans le futur.

Je pense à un protocole dans lequel l'adresse qui identifierait une
machine serait tout simplement un chemin entre moi et la machine que
je cherche à contacter.

[...]

Pour contacter un hôte il me suffit d'émettre un datagramme IP en
remplaçant les champs source et destination par le chemin de l'hôte
que je désire contacter. Un chemin étant la liste de tous les routeurs
qui me séparent de l'hôte à contacter suivi de son ip. Pour me
répondre, l'hôte contacté pourra connaitre mon chemin en lisant le
chemin à l'envers.

Attention, le routage ne peut pas toujours être symétrique.

Oui si on impose à l'hôte un routeur à l'avance.
Si dans le réseau, il y a 3 routeurs (d'ip respectives r1, r2, r3), le
chemin d'un hôte distant pourrait être
mon_ip.r1.... ou mon_ip.r2.... ou encore mon_ip.r3....
Dans le protocole proposé, le premier routeur à contacter est précisé
dans le chemin de l'hôte distant.

Dans IP, le premier routeur est arbitraire. Pourquoi le premier routeur
serait arbitrairement fixé mais pas les suivants?

Il manquerait pas grand chose à ipv4 pour le rendre fonctionnel à ce
principe, il suffit juste de rajouter un champ dans le datagramme qui
indiquerait la longueur d'un chemin, le chemin remplacerait les champs
source et destination.

En fait ça ressemble à quelque chose qui existe déjà dans IP mais qui à
ma connaissance n'est pas utilisé : le routage source (source routing).

Je ne connais pas. Ce ne serait pas utilisé dans les champs d'option?
Sinon je serai très interessé d'avoir de la documentation sur le routage
source.

On Sat, 20 Nov 2004 02:08:20 +0100, Julien Arlandis <juliendusud@free.fr>
wrote:

Usenet qui s'appuye sur le protocole de diffusion NNTP présente une
meilleure approche de ce que pourrait être un internet anarchique.
L'intelligence de ce protocole, c'est qu'il ne recquiert aucun contrôle
centralisé, aucune autorité ne peut par exemple contrôler l'ensemble
des articles d'un newsgroup non modéré.

Il y a un point que tu ignores et qui a son importance: chaque noeud doit
avoir un nom unique (sinon il ne recevra pas les messages qui sont passés
par un autre noeud que lui). On utilise donc généralement des noms de
domaine, qui sont attribués par une autorité centralisée avec une vague
hierarchie.

D'autre part, aucune autorité sur Internet ne peut contrôle l'ensemble des
paquets d'un protocole de son choix...

L'attribution des IP suit une hiérarchie mais le routage n'en suit pas
vraiment, à chaque interconnection de 2 réseaux, il y a brisure de la
hiérarchie. C'est ce qui fait d'internet une toile et non un arbre.
Du coup l'attribution hiérarchisée des adresses IP n'est plus vraiment
justifiée.

Si, parce qu'aux extrémités de la toile, on a bien des arbres (tous les
clients non-multi-homés d'un ISP passent par cet ISP). L'attribution
d'adresses de façon hierarchique *à ce niveau* permet de limiter le nombre
de routes dans la partie "toile" (le default-less Internet).

Si par exemple, le chemin de mon DNS est A|B|C|D|mydns et qu'il me
fournit le chemin de google : D|J|K|L|M|google, je saurai que le
chemin que je dois utiliser pour contacter google est :
A|B|C|D|J|K|L|M|google

Ca ça voudrait dire que tout le trafic passe forcément par ton "DNS". Et
si le chemin jusqu'à ton "DNS" casse?

Note qu'en pratique, c'est équivalent à ce qui se passe en réalité: on
suite des routes par défaut jusqu'à ce qu'on arrive à un routeur dans le
"default-less Internet" (un routeur qui a une table de routage complète).
La seule différence (et elle est de taille) étant qu'on travaille "hop by
hop" et pas en source-routing.

Dans mon exemple, le chemin de google enregistré par mon DNS est
D|J|K|L|M|google, si K disparait, le chemin de L deviendra D|J|L
et le chemin de google deviendra D|J|L|M|google

Et comme fais-tu pour demander au DNS ce "chemin"? Tu lui donnes donc une
adresse ("google"), et c'est bien elle l'adresse, pas le chemin complet...
De surcroît comment ton DNS sera-t-il informé des changements de
topologie? Ah il utilise BGP4? C'est donc un routeur...

Ce sera le rôle du serveur DNS de fournir d'autres chemin quand un
chemin n'est pas opérationnel.

Les routeurs y arrivent très bien tout seuls, merci pour eux.

L'avantage de ce principe c'est qu'un hôte pourrait choisir n'importe
quelle adresse IP de son choix qui l'identifierait au sein d'un réseau,
(la seule restriction étant évidemment que deux hôtes dans un même
réseau n'aient pas la même IP).

En théorie, ça marche comme ça dans l'Internet (le but original de la
"hiérarchie" sus-citée -- qui n'en était pas une au départ, il n'y avait
que l'IANA -- était uniquement d'assurer l'unicité des adresses
attribuées). Le problème, c'est qu'il est quasiment impossible de
maintenir une table de routage de 2^32 entrées distinctes et surtout de
propager toutes les modifications de cette table de routage. La solution
est donc l'aggrégation: au lieu de considérer les adresses une par une, on
les groupe dans des blocs les plus gros possibles, ce qui diminue d'autant
le nombre de routes. Et déjà là c'est pas tous les jours trivial!

Il manquerait pas grand chose à ipv4 pour le rendre fonctionnel à ce
principe, il suffit juste de rajouter un champ dans le datagramme qui
indiquerait la longueur d'un chemin, le chemin remplacerait les champs
source et destination. Il faudrait également rajouter un champ pour
indiquer au routeur qui reçoit un paquet à transmettre sa position dans
le chemin.

Tu devrais peut-être lire la spécification du protocole IP, tu y
découvrirais nos amies les options de source-routing. Qui sont très
activement ignorées par la plupart des routeurs, puisque ça pose des
problèmes de sécurité et de respect des politiques de chacun.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/