[bcop] [Bcop-gc] documentation ipv6 prefix

Hi,

I can understand both opinions, but prefer to keep one /32 as there should be enough bits for a 
clear organization assignment in documentations like
- 2001:db8:axx::/40
- 2001:db8:bxx::/40
- 2001:db8:cxx::/40
...

that way there are one /40 for organization a, b and c if someone wouldn't like to call them 1, 2 or 
3.

It is also possible split above prefixes like
- 2001:db8:a1xx::/40
- 2001:db8:a2xx::/40
- 2001:db8:b4xx::/40
- 2001:db8:b5xx::/40
...
For organization A region one and two + organization B region four and five where every region 
of an organization can still delegate 2^8 /48 to customers.

Karsten

Am Samstag, 23. August 2014, 06:11:07 schrieb Geoff Huston:
> Hi
> 
> Since I've been cc'ed here, and since you've asked, my personal opinion is
> that a /32 in IPv6 is perfectly capable of describing network scenarios
> that encompass some 4 billion network prefixes, assuming a 64 bit interface
> identifier space. If you are considering writing documentation that
> requires in excess of 4 billion distinct network prefixes than I would
> seriously suggest that you have problems far far greater than trying to map
> your intended example into a /32 prefix. :-)
> 
> I personally see no rational basis for further documentation prefixes, and
> certainly no rational basis for reviving 3ffe.
> 
> Geoff
> 
> On 22 Aug 2014, at 10:56 am, ?? <mayan at bupt.edu.cn> 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.
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/bcop/attachments/20140824/55700150/attachment.html>