proposal for RIPE's IPv6-address space structure

>Daniel Karrenberg writes:
> >
> > How about just using the 56 bits for local-IR+subscriber?
> > The boundary does not need to be fixed at all.
> > Then use a similar scheme than the present IPv4 one to determine the
> > size of allocations to local IRs (provider):
> > Fixed size for new local IRs and further allocations based on
> > established usage rate.
> >
>Using only 56 bits for the IR would effectively defeat the possiblity
>of using MAC / ESI addresses as the low 48 bits of an IP address.
>
>Pete

Not to mention ESI and 1-byte selector, as is usual for ATM NSAP addressing,
if we want to mix-and-match NSAP and IPv6 addresses.

At Sohonet we are currently working out our NSAP addressing scheme.

We have 4.5 bytes of prefix under the UK DCC scheme, and we add another
nibble to define an 'escape hatch' version number for our numbering scheme,
and bring it to byte alignment.

We also have 6 bytes of ESI, and 1 byte of SEL, from common ATM practice.
So, we now have only 20 - (4.5 + 0.5 + 6 + 1) = 8 bytes of NSAP address space
left for our own internal purposes.

We would very much like to have an addressing scheme where IPv6 and NSAP
addresses
can, at the very least, be derived algorithmically from one another.

Our design criteria for our NSAP addressing scheme:

>
>The proposed addressing proposal should allow:
>
>   Easy interpretation by human beings (eg byte aligned or nibble-aligned
>fields)
>   A version field, to allow changing the numbering scheme later.
>   Compatibility with IPv6, if possible.
>   Easy NSAP filtering by _organisation_ and class of service, bearing in
>   mind that some filtering may only be possible by strict prefix.
>   Efficient routing
>   Support of multiple providers, multi-homing and diverse routing.
>   Some customer-specified numbering for internal use (???)


-- Neil Harris
   Sohonet Limited
   http://www.sohonet.co.uk/