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@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@go6.si>

> > Recipient:bcop <bcop@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@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@elists.isoc.org

> > https://elists.isoc.org/mailman/listinfo/bcop-gc