BOUNCE 6bone@zephyipv6 delegation plan commetns

[bmanning@ISI.EDU]

> Subject: Re: v6 message to IANA - followup
> To: 6bone@ISI.EDU
> Date: Fri, 28 May 1999 09:31:11 -0700 (PDT)
> 
>  > PROVISIONAL IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT
>  > (28 May 1999)
>  > Scheduled revision: Formal revision of this document is scheduled to be
>  > commenced by 1 October 1999.
>  > 
>  ....
>  > 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
>  > sub-TLA ID   16                 28             /29        13
>  > Reserved     29                 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).
>  
>  This will pose a problem with most all existing DNS code.  DNS code 
>  tends to follow octect or nibble alignment.  Bit alignment is proposed
>  but not developed.  Widescale deployment is not expected within the
>  next 18 months. Use of this delegation framework will inhibit the use
>  of DNS with IPv6. (see the recent 6bone discussion on subTLA assingment
>  policy. 05may1999 posting from Bob Fink)).
>  
>  
>  > 4.2.6 Registering and Verifying Usage
>  > 
>  > Each TLA Registry is responsible for the usage of the sub-TLA address space
>  > it receives and must register all end-site assignments and ISP allocations
>  > in the database of the Regional IR in its region. 
>  
>  	So a distributed service aka, rwhois or DNS is not acceptable
>  	as a registration service?  To me, this insistence on centralized
>  	databases will be a significant hurdle in growing the Internet
>  	two more orders of magnitude.
>  
>  > Registered end-sites must be connected and reachable. To verify this, the
>  > relevant Regional IR is entitled to ping /48s within end-sites. 
>  
>  	Again, this indicates a lack of vision for future Internet
>  	developments.  There is significant developmental work being
>  	done for loosely coupled networks, e.g. networks that are
>  	only "attached" to the rest of the Internet sporadically.
>  
>  > 6. DNS AND REVERSE ADDRESS MAPPING
>  > 
>  > [To be written..]
>  > 
>  	See my comments above on why 13 bits are wrong.
>  
>  	
>  While I don't expect my comments to be persuasive to the RIR juggernaut,
>  I feel they should be heard. If others feel they are relevent, then
>  perhaps they can try and persuade these folks that they are promoting
>  seriously flawed policies.
>  
> --bill 
> 


-- 
"When in doubt, Twirl..."  -anon