Bonjour,
comme mon AS a été cité dans ce qui ne faut pas faire...
Concernant l'ipv6 nible ou dichotomie ou autre?
Dans un /64 on peut mettre combien de service/produits/services ?
Je vous laisse répondre mais il me semble que le stock est conséquent (mais en
gros tant qu'on pourra mettre des
Le 10/11/14 17:34, Lionel Drevon a écrit :
Cela amène la question suivante : pourquoi voulez-vous augmenter cette
plage?
Cela n'est pas la question. /64 c'est un subnet en ipv6. Il existe plein
de raison de regrouper plusieurs subnets.
L'allocation séquentielle signifie allouer les
Le 10/11/2014 17:34, Lionel Drevon a écrit :
Concernant l'ipv6 nible ou dichotomie ou autre?
Dans un /64 on peut mettre combien de service/produits/services ?
Un seul, entre deux hôtes.
Je précise : oui on peut mettre plus de deux hôtes sur un /64, comme on
l'a toujours fait en IPv4. On
Plop,
Juste une brève réaction et rappel suite à un tweet de Bortz qui a vu
des /64 trainer dans la DFZ (enfin via BGPmon) :
- IPv6 ne se désagrège pas en dessous de /48. Jamais. Et en pratique
n'annoncer que le /32-29 suffit.
- IPv4 ne se désagrège que dans trois cas :
* sous-allocation,
*
Hello Jérôme,
Il suffit d'avoir les filtres adéquats, et filtrer le longer than /48...
comme tout le monde filtre probablement jusqu'au /24 (voire moins) dans
le pretty old legacy IPv4...
En ce qui me concerne, j'ai pas vu la différence, donc ca m'est égal...
--
Clément Cavadore
On Mon,
Le 03/11/2014 14:05, Jérôme Nicolle a écrit :
[...]
http://bgp.he.net/AS43142#_prefixes6
('tin, en allocation séquentielle en plus. Ca se découpe par dichotomie
l'IPv6 !!!)
Tu pourrais préciser cette remarque, je n'arrive pas à la saisir. Pour
moi, le problème est au contraire qu'il y a eu un
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bonjour,
On 03/11/2014 14:05, Jérôme Nicolle wrote:
- IPv4 ne se désagrège que dans trois cas :
* sous-allocation,
* load-balancing pour un réseau d'eyeball mal géré et/ou avec de mauvais
équilibres entre transits,
* protection contre le
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 03/11/2014 16:30, Sylvain Vallerot a écrit :
Tu sembles oublier le multihoming classique.
Couvert par la sous allocation.
Si tu as un /21 utilisé d'un bloc par le(s) même(s) routeur(s), même
multihomé, les bonne pratiques (en mode bon sens
Le 03/11/2014 14:44, Julien VAUBOURG a écrit :
Tu pourrais préciser cette remarque, je n'arrive pas à la saisir. Pour
moi, le problème est au contraire qu'il y a eu un découpage dichotomique
avec le 33e bit, ce qui coupe un nibble de façon crade. Mais les /48 en
séquentiel, ça paraît plutôt
A lire un grand classique :
https://tools.ietf.org/html/rfc3531
Ca fait quand même 11 ans qu'on explique que l'allocation séquentielle, c'est
pas bon.
En ce qui concerne l'allocation par nibble :
http://www.slideshare.net/cwestin63/ipv6-address-planning-30305109
A noter que ceci est valable pour
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/11/2014 16:48, Jérôme Nicolle wrote:
Le 03/11/2014 16:30, Sylvain Vallerot a écrit :
Tu sembles oublier le multihoming classique.
Couvert par la sous allocation.
Mais tu peux multihomer un bloc assigné sans le sous-allouer, donc
Le 03/11/2014 19:40, Sylvain Vallerot a écrit :
Mais tu peux multihomer un bloc assigné sans le sous-allouer, donc
qu'est-ce que tu entends par sous-allocation du coup, ta définition
ne semble pas être celle du Ripe ?
Parce que tu vas oser annoncer un inetnum pas enregistré dans les IRR ?!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/11/2014 19:56, Jérôme Nicolle wrote:
Le 03/11/2014 19:40, Sylvain Vallerot a écrit :
Mais tu peux multihomer un bloc assigné sans le sous-allouer, donc
qu'est-ce que tu entends par sous-allocation du coup, ta définition
ne semble pas
13 matches
Mail list logo
