This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[bcop] Fwd: [Bcop-gc] documentation ipv6 prefix
- Previous message (by thread): [bcop] [Bcop-gc] documentation ipv6 prefix
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Alex Saroyan
alexsaroyan at gmail.com
Fri Aug 22 17:56:07 CEST 2014
Hi, From another view maybe it is better to "teach" people to better understand ipv6 subneting and prevent possible classfull style misconceptions. Best. /Alex "Jan Zorz @ go6.si" <jan at go6.si> wrote: >On 22/08/14 02:56, 马严 wrote: >> Hi, Jan and all, >> >> As RFC3849 specified, the prefix reserved for documentation is a /32 block, >> 2001:DB8::/32 >> while people can use the following: >> net A = 2001:db8:1::/48 >> net B = 2001:db8:2::/48 >> net C = 2001:db8:3::/48 >> we can also use >> net A = 2001:db8:1::/48 >> net B = 2001:db8:8000::/48 >> net C = 2001:db8:a000::/48 >> for being easy recognized as separated networks. > >Yes, I agree, but this is different just to some limited extent. People, >not very familiar with IPv6 and on their learning curve might mistakenly >understand this as prefixes in one network. To be really sure they >distinguish between the networks (being just different local networks or >different AS-es) I think completely different IPv6 prefixes should be >used, visually different from the first "character" on... > >I thought this is what Japanese colleagues are suggesting... > >(Including Seiichi-san to cc:) > >Cheers, Jan > >> The only shortcoming that I can think of is, because 2001:db8::/32 is >> one big block, when being used to describe >> inter-domain network topology, /32 address block may easily be >> considered as all networks belong to one organization. >> Any comment? >> >> I also cc:ed this email to the co-author of RFC3849, G.Huston, Chief >> Scientist from APNIC, for further discussion. >> >> Best regards, >> --MA Yan >> >> ----- reply email ----- >> *Sender:*Jan Zorz @ go6.si <jan at go6.si> >> *Recipient:*bcop <bcop at ripe.net> >> *Time:*08/21/2014 22:11:55 >> *Subject:*[bcop] Fwd: [Bcop-gc] documentation ipv6 prefix >> >> >> Dear RIPE BCOP community, >> >> I got a question from Seiichi Kawamura, JANOG BCOP co-chair and I think >> this suggestion/question would be best if discussed here on this >> mailing >> list (and maybe also on IPv6 WG ml). >> >> Please read below. >> >> Cheers, Jan >> >> -------- Original Message -------- >> Date: Tue, 19 Aug 2014 10:04:56 +0900 >> From: Seiichi Kawamura <kawamucho at mesh.ad.jp> >> >> Fellow BCOPers >> >> Hi there. >> Some folks in Japan, especially tech >> bloggers and tech documentation producers >> are saying that we need more ipv6 documentation >> prefix than just 2001:db8::/32 >> >> When describing a classic 3 prefix >> network topology they would use >> >> net A = 2001:db8:1::/48 >> net B = 2001:db8:2::/48 >> net C = 2001:db8:3::/48 >> >> where as with v4, >> >> net A = 192.0.2.0/24 >> net B = 198.51.100.0/24 >> net C = 203.0.113.0/24 >> >> The 3 IPv6 prefixes are too similar and it's >> intuitively hard to tell if the 3 prefixes are >> talking about a network, or is it 3 separate networks. >> I guess this is bad especially for educational >> tutorial documentation. >> >> So I'm thinking that if there are 2 more prefixes >> defined as documentation, I would say that's enough. >> We can maybe even revive 3ffe:: and make that documentation purpose. >> >> However, I'm intersted in hearing opinions from other regions. >> Do you think there are any such needs in your region? >> >> -Seiichi >> >> _______________________________________________ >> Bcop-gc mailing list >> Bcop-gc at elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/bcop-gc >> >> >> > >
- Previous message (by thread): [bcop] [Bcop-gc] documentation ipv6 prefix
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ BCOP Archives ]