Adressage IP
Un article de Toulouse Sans Fil, un réseau wifi libre sur Toulouse.
Accueil | Technique | Théorie Réseau | OLSR | adressage IP
| Sommaire |
Introduction
Adressage IP local
Ces informations seraient mieux dans un doc appelé architecture réseau
Afin de ne pas rentrer en conflit avec le réseau Internet, il est souvent utilisé pour les réseau locaux des plages d'adresses du privée. Ces plages d'adresses sont le plus souvent de la famille : 10.X.Y.Z et 192.168.X.Y. Ces adresses étant considérées comme privées, elles ne sont pas routées par les principaux routeurs vous donnant accès à Internet. Il n'y a donc aucune possibilité de confusion entre les 2 réseau.
Il est donc souhaitable pour un réseau tel que TSF de se baser sur ce principe d'adressage privé. Nous souhaitons utiliser le jeux d'adresses donnant le maximum d'adresses disponible de facon a pouvoir étendre au maximum le réseau. Il serait possible d'utiliser un adressage IP sur 6 octets (IP v6), mais bien du matériel et logiciel ne le supporte pas encore de facon native.
Réseau en 10.X.Y.Z
Nous voici avec un réseau que nous avons la possibilité d'organiser suivant différentes modalités. Les 3 lettres X,Y,Z sont libres et varient de 0 à 255 ce qui laisse environ 255^3 possiblités.
Zones
Le réseau TSF étant appelé a grandir, il faudra très probablement l'organiser en zones. Des zones géographiques et tres probablement des zones d'adressage IP a la maniere des codes postaux de la poste (31100, 31500).
Communication intra-zone et extra-zone
Quand le réseau sera suffisament developpé, il faudra assurer des communications dans chaques zones. Probablement que chaque point de la meme zone verra tous les autres points directement. Cependant, pour des raisons d'optimisation de traffic, il peut etre envisageable de réaliser des formes de "cellules" et des portes de communication entre chaque cellules. Tout ceci est a définir.
Proposition de Frédéric Moine
D'autres communauté françaises ont déjà commencé l'utilisation de la classe A 10.0.0.0/8.
La base de travail est : 10.département.ville.wifiste
Il est notable que si on se conforme à cela, ne peut y avoir que 254 wifistes dans une ville... Difficile à concevoir sur Toulouse....
On va donc partir sur le principe 10.département.village/quartier.wifiste
A partir de là, si on depasse 254 wifistes sur un village ou quartier, il sera toujours possible de redécouper certains ou d'en regrouper d'autres.
Cela pourait donner quelque chose du genre :
| 10.31.1 à 10.31.49 | Toulouse | (12446 wifistes potentiels dans 49 quartiers) |
| 10.31.50 à 10.31.99 | Réservé pour plus tard | (12446 libres pour Toulouse) |
| 10.31.100 à 10.31.149 | Banlieue proche | (12446 wifistes potentiels dans 49 villages) |
| 10.31.150 à 10.31.199 | Réservé pour plus tard | (12446 libres pour la banlieue) |
| 10.31.200 à 10.31.249 | Banlieue lointaine | (12446 wifistes potentiels dans 49 villages) |
| 10.31.250 à 10.31.254 | Réservé à l'infrastructure ou autre |
Si d'autres besoins se font sentir, il est possible de recuperer en accord avec les autres communautes un 10.xxx car je le rapelles, il n'y que 94 départements en métropole...
Il reste maintenant à prendre un plan ou une carte et à attribuer tout cela géographiquement.
Cette méthode est donc liée à l'équation : 1 Wifiste = 1 IP
Pour ceux qui désirent relier tout leur LAN (filaire) sur TSF, il faudra jouer avec le NAT. Le LinksysWRT54g sous OpenWRT est tout à fait apte à faire cela.
Pour ceux qui désirent relier leur portable wifi au réseau, la solution est techniquement théoriquement possible. Pour le moment, et tant que les tests en cours ne seront pas terminés, il est préférable de dire qu'il faut alors prévoir un second réseau wifi sur le LAN dédié à ce portable.
Je ferais des shéma sur les possibilités le plus rapidement posible pour clarifier tout ça.
Ceci est une base de travail... Et n'a pour l'instant rien d'officiel.
Remarques
Uniquement dans cette partie merci...La base est interessante, il faudrait qu'on se mette d'accord pour "normaliser" ça ou pas. A voir aussi : pour l'adressage dans Toulouse inta muros, possibilité d'utiliser les plans dispos ici : http://www.mairie-toulouse.fr/plan/Plan_de_Ville.html - Aurélien ROUZAUD
Marc - j'avais pensé à une formule de conversion entre position géographique en degres, minutes (pas secondes) et adresse IP. Il y aurait un lien direct entre une adresse IP et une zone géographique. Chaque IP etant dans la meme zone géographique auraient le meme masque et les communication dans cette zone seraient directes. Hors de cette zone, il faudrait passer par la route par defaut. Il faudrait donc determiner pour tout la france un mécanisme de répartition mieux ciblé que 10.département.X.Y et aussi plus fin que 10.latitude.longitude.Y et qui permette d'avoir un gaspillage d'addresse minimum. Ce serait donc une fonction de conversion de cette forme :
ip = fonction($lat, $long);
avec :
- $lat variant de 0 à 10 (environ, prendre une carte pour etre certain), l'amplitude est de 5 à 10 maximum
- $long pour la longitude (meme chose)
- il reste 2 octets disponibles (on peut donc répeter l'opération avec les minutes pour alimenter l'octet 3 de l'ip)
- et le dernier octet de l'IP est un numéro d'ordre dans un annuaire,
- une zone de 1 minute de large vaut 111km/60 = 2km, ce qui donne exactement 254 IP disponibles par zone,
- si on veut plus d'IP par zone, il faut decouper d'une maniere différente,
et 60minutes (lattitude) x 60 minutes (longitude), cela ne tient pas du tout sur le 3ieme octet, cela sous-entent que la aussi une partie des informations a été tronquée.
un adressage IP national est assez utopique, il est donc possible de garder le meme principe en adressage local, mais en changeant la distribution des octets face aux coordonnées geographiques du node. l'avantage d'un tel procédé est de pouvoir disposer instantanément d'une adresse IP a partir du moment ou on fourni les coordonnées geographiques d'un node. Il suffit d'implementer sur un serveur Web en php l'algorithme de conversion et de le rendre public. apres une courte discution sur le chat avec Fred, il s'avert qu'il faut trouver un mécanisme tel que la distribution des adresses IP soit assez proche quand les coordonnées sont proches et plus éloignées quand les points s'éloignent.
pour cela, il suffit de : convertir en 2x8 bits l'espace géographique adressable, distribuer et combiner les 2x8 bits sur 2 octets, en prenant en premier les bits de poid fort suivis des bits de poid faible,
par la suite, la largeur du mask est directement proportionnelle a la superficie de la zone souhaitée. Il suffit d'adapter cette largeur de mask en fonction de la largeur voulue. ex
- 10.12.34.XX/24 : petite zone de couverture, peu de points d'acces visibles directement, les autres sont visibles via le routage,
- 10.12.34.XX/16 : zone plus étendue.
- 10.12.34.XX/8 : tous les ap sont directement accessibles, sans routage. Il devient donc nécessaire que l'AP connaisse via sa table de routage la topologie du réseau, grace au protocole OLSR par exemple.
Remarque (origine : Grompf) : Concernant le NAT, il est a noter qu'il est utilisable comme tête de pont comme d'habitude. Mais il est possible de faire sans : le protocole OLSR autorise la déclaration d'hotes externes que le relais routera localement. Il est aussi possible de router plusieurs interfaces hertzienne ou filaire, sous le contrôle d'OLSR : ce qui permet d'avoir une grappe de machines disponibles en "relai" sur le réseau en accès direct (un exemple : un serveur ntp strate 0 à temps de réponse fiablilisé, vu que des accès à des horloges au césium sont maintenant grand public). Ceci au prix bien sûr de l'affectation de plusieurs IPs à la même personne physique.
Remarque (origine : Grompf) : Une plage d'adresses réservée aux machines en test serait très utile. Pas de garantie sur l'usage de ces adresses, qui pourront être non routables selon les désidératas des ops.
Remarque (origine Grompf) : la gestion intra-zone et extra zone est gérée dynamiquement par le routage OLSR. Le protocole gère directement ses voisins à HOP+1, et séléctionne automatiquement les relais de sortie de zone "Hertzienne" parmis ces voisins à HOP+1 afin d'avoir la couverture maximale à HOP+2. Chaque relais opere ainsi une couverture dynamique et optimale des sorties de zone "Hertienne". Il n'y a a priori pas besoin de protocoles spécifiques du type de ceux utilisés par les installations filaires à grande couverture.
Par contre, le point a regler me semble être le routage hors d'un agglomérat Hertzien vers un autre : donc le forcage ou la création de gatways OLSR pouvant au besoin passer par un "fil" de secours en attendant la densification des relais.
(idée : dès qu'on à un relais opérationnel avec de l'adsl avec IP fixe dispo, on devrait être en mseure de proposer l'experience de ponter des ilots, et meme de ponter par exemple avec les lillois).
A mon avis le coupler le zonage de routage et le zonage IP tient du jeu d'un équilibriste du fait du dynamisme de la chose vu qu'on est plus dans un monde plein de fils, et qu'on utilise un systeme de routage "global" qui se fout de la géographie.
Aussi je proposerais de simplifier l'affectation des adresses IP en partant de la base 10.x.x.x/8. (Ceci pour les personnes ne sachant pas coupler deux réseaux se superposant).
A l'échelle métropolitaine, nous avons 94 départements... un calcul rapide en base deux nous donne une frontière voisine disponible de 127 départements possibles avec 33 "pseudo" départements en rab. Ce qui laisse donc 17 bits libres pour les utilisateurs... gérables assez simplement semble-t'il par les habitués des affectations d'ID. Ce qui nous fait donc 131072 utilisateurs bruts de fonderie, soit en simplifiant travailler sur du 10.xxx.xxx.xxx/15. D'ici à ce qu'on en soit à saturer ça... l'IPV10 sera publiée. Et si il faut ce gerer ca à la mode monde/europe/france/dept/user, on passe viteuf à l'IPV6. ;o)
Une moulinette & database gérant les affectations avec un compteur et une table d'IP abandonnées pour le collecteurs de vide devrait être vite tombée par nos dieux du web.
Note : et si il y a des ziouzers baladeurs tant mieux pour eux... le systme de routage tolèrera ça tranquillement. On peut juste demander à un ziouzer de présenter patte blanche à une asso locale afin de faire sa migration départementale une fois celle-ci tenue pour ferme et définitive. Etre membre d'une asso sans fil française, travaillant sur les meme preceptes que TSF serait un critere nécessaire et suffisant.
Remarque (source : Grompf) : Nos amis belges ont eu une idée génialissime... à un tel point que je suis jaloux de ne pas l'avoir trouvée ! Suivre le lien qui arrive ci-après : Idée géniale de système d'adressage (http://reseaucitoyen.be/index.php?ExtensionPlanAdressage)
Remarque (source : Grompf) : Avec OLSR, il est question d'un routage à plat "universel" et entièrement décentralisé : un système d'adressage tout aussi décentralisé et tout aussi à plat me semble être la meilleure solution pour ce type d'architecture (et accéssoirement une bonne solution politiquement et socialement parlant).
Autant que faire se peut, il me semble raisonable d'éviter les limitiations d'une structure hiérarchique classique qui instaurerait des points durs dans ce plan d'adressage égalitaire et dans la structure même du réseau, d'un point de vue fonctionnel ou géométrique. Je vais faire mon petit Einstein d'opérette mais je vois le réseau dans son fonctionnement et sa disposition basique comme un nuage de points mobiles ou non (caractéristique dont on se moque : on a un protocole qui règle la question de la mobilité par lui même, il n'y aura jamais lieu de revenir sur le traitement des mobiles avec lui). Ces points papotant entre voisins en vue directe, et étant localisés sur un plan (posez des points sur une feuille de papier et regardez ce que cela donne).
D'un autre coté, il est tout à fait possible de changer de "dimension/espace/temps" et de déformer/plier le plan ou sont localisés les points (l'espace de routage OLSR). Pour mettre deux points éloignés en contact, il suffit soit de déformer le plan soit de le replier sur lui même : comme on deforme une plaque de cahoutchouc en appuyant dessus, ou comme on replie une feuille de papier. Une fois deux points mis artificiellement l'un en face de l'autre, ils sont capables de communiquer à vue entre eux.
Une autre approche imagée consiste à changer "d'espace-temps" et de "dimension" donc de changer de feuille de papier. ;o) Bref d'avoir un second réseau parallèle different d'OSLR ou même plusieurs réseaux qui permetent de créer des points de passage instantanés d'un endroit à un autre de l'espace de routage OLSR, mais en utilisant des lois de routage qui ne sont pas celles d'OLSR, et qui peuvent être par exemple des lois de routage hiérarchique avec toute l'infrastructure que cela implique.
Les répercussions physiques seraient "juste" les suivantes pour chaque point a "replier" :
- usage de routeurs OLSR multi-interfaces wifi ou ethernet (C'est dans la spec' d'OLSR) ayant tout son adressage IP dans le plan d'adressage 10.xxx.xxx.xxx à choisir selon nos futures discussion.
- usage d'un routeur externe d'une techno de comm identique ou non (wifi, ethernet, X25, aDSL) et utilisant des protocoles de routage differents capable de mettre en place un VPN strict à la plomberie extremement étanches aux intrusions et surtout aux fuites. Ce VPN permetrait de faire passer les données marchandes venant du routeur local OLSR à un routeur distant OLSR, tout en acheminant les données de contrôles entre les differents routeurs OLSR. Ce VPN pourra presenter plusieurs liens vers plusieurs routeurs OLSR distant via autant de routeurs VPN. Il devrait éventuellement être possible de travailler avec une serie de routeurs VPN differents pour disposer d'autant d'univers parallèles. Ici le VPN serait transparent pour sa connection vers le monde OLSR, et aurait son syteme d'adressage propre vers "l'exterieur".
Par l'usage de routeurs VPN externes, il est facile de démontrer par A+B=C qu'il n'y a pas d'interconnection entre réseaux, vu que le réseau externe ne peut pas communiquer avec le réseau OLSR, et inversement. L'interconnection à des réseau independant semble être elle parfaitement autorisée. (point restant cependant à éclaircir).
Note : l'usage massif de VPN peut demander l'usage d'un coprocesseur de chiffrage pour une soluce optimale, ou d'un cpu mammouthesque pour peu d'usage, beaucoup d'energie consommée et beaucoup de chaleur restituée.
Note-bis : le boulot s'organise en tranches dont les achèvements progressifs seront bons pour le moral une fois organisé en briques modulaires.
Note-bis-bis : non je n'ai pas fumé, et mon concept est très clair.
Remarque (source : Grompf) : Bon, on ne va pas se laisser impressioner... en attendant une solution simple voila une page de réservation d'adresses IP. Empilez vos IPs la dedans en respectant celles d'autrui. ;-) C'est ce qu'on appelle un appel du pied tout en largeur (taille 46).