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
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 bl
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
-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
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 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
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
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
-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
-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
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
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, 2014-1
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,
* load
13 matches
Mail list logo
