<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: v6 message to IANA


> The following message was sent to the IANA on behalf of the Regional 
> Internet Registries.  Once we receive approval from IANA on the v6
> policy guidelines, below, we'll be ready to begin making allocations.
> 
> Kim

	It was pointed out to me that instead of whining about
	this unfinished document, that it would be reasonable
	to suggest working alternatives to the flawed sections
	and text for some of the missing pieces.

> Although
> the document will be further developed and refined in the coming months -
> according to the input and experience gained during the initial period -
> the general community support for this document is strong enough to
> justify its implementation in its current form.

	Well not really but these suggestions might get things further
	down the road to RIR operational status.
 
> PROVISIONAL IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT
> 
> (28 May 1999)
> 
> 3. IPv6 TECHNICAL FRAMEWORK
> 
> 3.1 IPv6 Addressing Hierarchy
> 
> RFC 2374 specifies that aggregatable addresses are organized into a
> topological hierarchy, consisting of a public topology, a site topology,
> and interface identifiers. These in turn map to the following:
> 
> | 3|  13 | 8 |   24   |   16   |    64 bits                 |
> +--+-----+---+--------+--------+----------------------------+
> |FP| TLA |RES|   NLA  |  SLA   |   Interface ID             |
> |  | ID  |   |   ID   |  ID    |                            |
> +--+-----+---+--------+--------+----------------------------+
> |-- public topology---|  site  |     Interface              |
> |                     |topology|                            |
> +---------------------+--------+----------------------------+
> |                              |                            |
> |-------- network portion----->+<-----host portion----------|
> |                             /64                           |
> |-----------------------------------------------------------|

	This is a workable (for the DNS) model.

> 3.2 Initial IPv6 Addressing Hierarchy
> 
> A modified version of the addressing hierarchy described in section 3.1
> will be used for the initial IPv6 allocations. The first TLA prefix (TLA
> 0x0001) has been divided into further blocks, called "sub-TLAs", with a
> 13-bit sub-TLA identifier. Part of the reserved space and the NLA space
> have been used for this purpose.
> 
> This modified addressing hierarchy has the following format and prefix
> boundaries:
> 
> Format boundaries
> 
> | 3|    13    |    13   | 6 |   13   |   16   |     64 bits        |
> +--+----------+---------+---+--------+--------+--------------------+
> |FP|   TLA    | sub-TLA |Res|   NLA  |  SLA   |    Interface ID    |
> |  |    ID    |         |   |    ID  |   ID   |                    |
> +--+----------+---------+---+--------+--------+--------------------+

	This will not work with existing DNS code.  Guesses as to when
	bit level delegation will be supported are being tabulated.
	While the existant CNAME hack should work, this is asking 
	the delegates to perform significant extra work.

> Prefix boundaries (starting at bit 0)
> 
>             number of the   number of the           ID
>             left-most       right-most       longest   length
>             bit             bit              prefix    (in bits)
>             ************    ************     *******   ********
> TLA ID       3                  15             /16        13

	Would work just fine at this level:

> sub-TLA ID   16                 28             /29        13

	To follow existing 6bone convention, this would better
	be represented as:

  sub-TLA ID   16                 27            /28         12

> Reserved     29                 34
	
	And this would change to:

  Reserved    28                  34


> NLA ID       35                 47             /48        13
> SLA ID       48                 63             /64        16
> 
> For purposes of a "slow start" of a sub-TLA, the first allocation to a TLA
> Registry will be a /35 block (representing 13 bits of NLA space). The
> Regional IR making the allocation will reserve an additional six bits for
> the allocated sub-TLA. When the TLA Registry has fully used the first /35
> block, the Regional IR will use the reserved space to make subsequent
> allocations (see section 4.2.5).

	Make it 12 bits and things will work much better with
	the DNS. 
	Yes, RFC 2450 does state:
	"The choice of 13 bits for the TLA field was an engineering
      compromise.  Fewer bits would have been too small by not
      supporting enough top level organizations.  More bits would have
      exceeded what can be reasonably accommodated, with a reasonable
      margin, with current routing technology in order to deal with the
      issues described in the previous paragraphs." 

	However this choice did not consider the state of DNS.  
	And we see that although RFC 2450 makes a proposal for 
	sub-TLA assignment along the lines adopted by this RIR proposal,
	the operational 6bone has determined that neither the RFC 2450
	proposal for sub-TLA assignment nor this proposal will work in
	practice.
	

 
> 4.2.3.2 Multihomed Sites
> 
> [to be written]

	Yow! and how many of these sites -aren't- multihomed now?
	
> 
> 6. DNS AND REVERSE ADDRESS MAPPING
> 
> [To be written..]

	More ickyness. Here is some verbage, based on the modified
	delegation process as listed above.
-------------------------------------------------------------------

	Many applications require valid DNS mappings exist before
	correct operation occurs. The IANA has caused a zone to
	be created for mapping IPv6 addresses to regular DNS labels.
	This zone is functionally identical to the IPv4 zone, 
	in-addr.arpa. The zone name is ip6.int.

	As of this writing, the zone contents are:

$ORIGIN int.
ip6             IN      SOA     ns.isi.edu. hostmaster.iana.net. (
                1925623 10800 900 604800 129600 )
                IN      NS      munnari.oz.au.
                IN      NS      imag.imag.fr.
                IN      NS      ns.isi.edu.
$ORIGIN 5.ip6.int.
f               IN      NS      NS.ISI.EDU.
                IN      NS      munnari.oz.au.
                IN      NS      zesbot.ipv6.surfnet.nl.
$ORIGIN f.f.3.ip6.int.
e               IN      NS      ns.isi.edu.
                IN      NS      imag.imag.fr.
;

	These two delegation points are for the historical 
	IPv6 delegation model (f.5.ip6.int.) as described in RFC1897.
	and the current 6bone delegation (e.f.f.3.ip6.int) as 
	described in RFC2471.
	The current 6bone delegation is a valid TLA under the
	currently existant and proposed delegation guidelines.

	With the adoption of this proposal, the IANA will direct that
	delegations will be made to each RIR, provided
	it supplies the IANA with a specific request for a delegation
	and at least two working nameservers. 

 
............

	More can/should be added to this section, in particular
	the apparent overlaps in historical and proposed delegation
	practice.

--bill





<<< Chronological >>> Author    Subject <<< Threads >>>