Re: v6 message to IANA
- Date: Mon, 7 Jun 1999 15:13:45 -0700 (PDT)
> 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
