Subject: (IPng 6870) Re: W.G. Last Call on "Initial IPv6 Sub-TLA ID Assignments"

From: Marc Blanchet <[email-masked]>
Date: Wed, 09 Dec 1998 22:50:46 -0500

Hi,
	I have a modification to propose about the initial assignments to subtlas
by registries. 

From draft-ietf-ipngwg-iana-tld-00.txt:
----------------------------------------------------------------------
   As specified in [TLA-RULES] assignments of Sub-TLA ID's will be done
   in blocks.  The initial assignment of Sub-TLA ID's to registries will
   be in blocks of 64 Sub-TLA ID's.  These assignments are as follows:

      Binary            Range (Hex)       Assignment
      ----------------  ---------------   -------------------
      0 0000 00XX XXXX  0x0000 - 0x003F   IANA
      0 0000 01XX XXXX  0x0040 - 0x007F   APNIC
      0 0000 10XX XXXX  0x0080 - 0x00BF   ARIN
      0 0000 11XX XXXX  0x00C0 - 0x00FF   RIPE
      0 0001 00XX XXXX  0x0100 - 0x013F   (future assignment)
      0 0001 01XX XXXX  0x0140 - 0x017F   (future assignment)
      0 0001 10XX XXXX  0x0180 - 0x01BF   (future assignment)
      0 0001 11XX XXXX  0x01C0 - 0x01FF   (future assignment)
      0 0010 00XX XXXX  0x0200 - 0x023F   (future assignment)
          .   .    .
          .   .    .
          .   .    .
      1 1111 11XX XXXX  0x1FC0 - 0x1FFF   (future assignment)
------------------------------------------------------------------------

Since the first 3 bits are 001 and then 13 next bits (TLA ID for subtlas)
are 0x0001, then the leftmost 16 bits of the 128 bits are now fixed. We
then try with the draft to assign the 13 next bits.  

Then, in order to be more flexible, I think we should begin using leftmost
bits for the 13 bits of the Sub-TLAs for the registries and ask them to
grow from the either the center or the rightmost bits. So we would be able
to change the boundaries if in the future, the number of bits chosen in
1998 were not the best we will find in N years. Changing the boundaries
mean that a larger number of either subtlas or NLA can be used without any
harm. 
 
So the allocation would be:

      Binary               Range (Hex)       Assignment
      -------------------  ---------------   -------------------
      1000 000X XXXX XNNN  0x8000 - 0x81FF   IANA
      0100 000X XXXX XNNN  0x4000 - 0x41FF   APNIC
      1100 000X XXXX XNNN  0xC000 - 0xC1FF   ARIN
      0010 000X XXXX XNNN  0x2000 - 0x21FF   RIPE
      1010 000X XXXX XNNN  0xA000 - 0xA1FF   (future assignment)
      0110 000X XXXX XNNN  0x6000 - 0x61FF   (future assignment)
      1110 000X XXXX XNNN  0xB000 - 0xB1FF   (future assignment)
      0001 000X XXXX XNNN  0x1000 - 0x11FF   (future assignment)
      1001 000X XXXX XNNN  0x9000 - 0x91FF   (future assignment)
          .   .    .
          .   .    .
          .   .    .
      1111 111X XXXX XNNN  0xFB00 - 0xFFFF   (future assignment)

(formatting note: I took the 16 bits boundaries for converting to hex so it
looks exactly as the second group of 16 bits in the complete addresses. N
are the NLA part. )

An interesting advantage is that the next blocks for a specific registry
will be contiguous to the first ones. For example, the next block for APNIC
will be 0x4200 - 0x43FF. 

The consequence is that it postponed the decision on the possible number of
registries and the maximum number of subtlas.  Which is great, since we
don't really know what those numbers will be. 

This proposal doesn't harm anything but allows more flexibility in the
future. Flexibility, especially if we don't know what will happen in the
future, is very useful. 

Regards, Marc. 

PS. some of the ideas about bits allocation are described in
draft-ietf-ipngwg-ipaddressassign-00.txt

At 10:25 98-12-01 -0800, you wrote:
>This is an IPng working group last call for comments on advancing the
>following document as an Informational RFC:
>
>	Title		: Initial IPv6 Sub-TLA ID Assignments
>	Author(s)	: B. Hinden, S. Deering, R. Fink, T. Hain
>	Filename	: draft-ietf-ipngwg-iana-tla-00.txt
>	Pages		: 5
>	Date		: 17-Nov-98
>	
>This document proposes initial assignments of IPv6 Sub-TLA Aggregation
>Identifiers (Sub-TLA ID) to the Address Registries and continued management
>of the IP6.INT domain.  It is intended as input to the IANA from the IETF
>IP Next Generation (IPNG) and Next Generation Transition (NGTRANS) working
>groups as an aid in starting the process of allocating IPv6 addresses.  It
>is not intended for any official IETF status. 
>
>The goal is to have the IPng w.g. advance this document so it can be
>approved and sent to the IANA to help expedite the process of starting the
>allocation of IPng addresses.
>
>Please send substantive comments to the ipng mailing list, and minor
>editorial comments to the author.  This last call period will end at the
>Thursday IETF IPng session on December 10, 1998.
>
>Bob Hinden / Steve Deering
>
>
>
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page:                      http://playground.sun.com/ipng
>FTP archive:                      ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to [email-masked]
>--------------------------------------------------------------------
>
>

-----------------------------------------------------------
Marc Blanchet			| [email-masked]
Viagénie inc.			| http://www.viagenie.qc.ca
3107 des hôtels		| tél.: 418-656-9254 
Ste-Foy, Québec		| fax.: 418-656-0183
Canada, G1W 4W5		| radio: VA2-JAZ
------------------------------------------------------------
Internet Engineering Standards/Normes d'ingénierie Internet
               http://www.normos.org
------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Thu, 10 Dec 1998 11:43:41 -0800

Marc,

When the draft was written, I considered doing it in the manner you
proposed (e.g., allocate left to right).  It came down to keeping
flexibility to possibly grow toward the TLA v.s. growing toward the NLA
field.  I didn't see a particular win in either approach so chose what I
considered to be simpler to allocate.

Also, the routing plan for these prefixes is to not aggregate by
registries, so there is no requirement to have contiguous blocks for each
registry.

Thanks,
Bob