Proposed change in 6bone pTLA 3FFE usage - 2nd (final?)

[bmanning@ISI.EDU]

> 
> Bill,
> 
> I don't understand your comment on this. There appears no conflict in the proposed 6bone TLA usage with any of the docs you mention (by the way, RFC1897 is obsoleted). I'm probably missing something obvious, so please say more.

 Well, in the document:
..........
 PROVISIONAL IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT
 (28 May 1999)
..........
	That the RIRs sent to the IANA, they adopt the 13bit cutpoint
	that was proposed in RFC 2450 and also proposed for the 6bone 
	and rejected for pragmatic operational reasons as described in
	you note to the 6bone (below).  RFC 2471 also calls for bit-level
	delegations.  My feeling is that the RIRs
	should also adopt this feature and not attempt to enforce
	delegations on bit bounds.

And while we can declare RFC1897 obsolete, the fact remains that it still
exists. (sort of like the all-ones, all-zeros broadcast values)  Unless I
am mis-reading the draft-ietf-ipngwg-iana-tla-01.txt document, this old
delegation falls right in the APNIC proposed delegation...  (I must be
misreading this)


 
> Thanks,
> 
> Bob
> 
> ===
> At 03:00 PM 6/7/99 -0700, bmanning@ISI.EDU wrote:
> >
> >Note that this change affects the existant documents that are being
> >used by the various RIR's on their delegation policies, i.e.
> >RFC 2450,
> >RFC 2471,
> >draft-ietf-ipngwg-iana-tla-01.txt
> >which appears to conflict with RFC 1897.
> >
> >	I think that this change, as implemented in the 6bone should
> >	be incorporated by the various RIRs in their operational documents
> >	and be used as a reference by the IANA in their discussions 
> >	about longer term delegation policies.  
> >	Yes, there is a movement afoot to get real bit level delegation
> >	deployed in the DNS but I don't think we can wait for that.
> >	
> >
> >> 
> >> 6bone Folk,
> >> 
> >> I recently proposed changing the pTLA 3FFE:/16 usage to allow future 
> >growth as the 6bone becomes used more for production. The current usage 
> >specifices an 8-bit pTLA (prefix 3FFE:xx00::/24), thus only providing for 
> >256 pTLAs, of which 57 are currently in use. 
> >> 
> >> The proposed change was to leave the lower half of the space usage as is 
> >(at least for now):
> >> 
> >> 	3FFE:0000::/24 thru 3FFE:7F00::/24  old 8-bit pTLA space
> >> 
> >> and starting at this point change to a 13-bit pTLA:
> >> 
> >> 	3FFE:8000::/29 thru 3FFE:FFF8::/29  new 13-bit pTLA space
> >> 
> >> Also, concern had been expressed about the odd bit size of the /29 in 
> >terms of implementing the reverse DNS path, so there was the possibility of 
> >making the new space fall on an nibble bit size boundary, say a /28 or /32.
> >> 
> >> 
> >> Comments generally seem to favor setting the new pTLA space at /28 on the 
> >grounds that 2048 pTLAs (half of a 12-bit pTLA space) is big enough, and 
> >that it makes the reverse path easier to specify for now. There was also a 
> >comment requesting that we don't require 8-bit pTLAs to convert to the newer 
> >pTLA space. 
> >> 
> >> 
> >> Thus I would like to change the proposal as follows.
> >> 
> >> The old 8-bit pTLA space will be reduced to use of the lower half of the 
> >space:
> >> 
> >> 	3FFE:0000::/24 thru 3FFE:7F00::/24  old 8-bit pTLA space
> >> 
> >> and starting at this point change to a 12-bit pTLA:
> >> 
> >> 	3FFE:8000::/28 thru 3FFE:FFF0::/28  new 12-bit pTLA space
> >> 
> >> I would also like to leave existing 8-bit pTLAs in place for the 
> >indefinite future. This issue can be reconsidered in the future as usage of 
> >the new 12-bit space dictates. 
> >> 
> >> It should also be noted that there is no planned policy at this time for 
> >requiring pTLA holders that acquire a TLA or sub-TLA allocation to renumber 
> >out of their pTLA. This issue can also be reconsidered in the future as 
> >usage of the new 12-bit space dictates. 
> >> 
> >> 
> >> I would like to cease the allocation of /24 8-bit pTLAs at this time, and 
> >move to the new /28 space. Hearing no convincing arguments to the contrary, 
> >I will assign the next pTLA as a /28. As there are no outstanding pTLA 
> >requests in the queue, it makes at least a two week delay in implementing 
> >this. Comments to the list please.
> >> 
> >> 
> >> Thanks,
> >> 
> >> Bob
> >> 
> >> 
> >> 
> >
> >
> >-- 
> >--bill
> 
> 
> 
> ---
> Bob will be on travel from June 9 until the Oslo IETF meeting (July 11-16), and will not be responsive to email until July 21. Please direct 6bone & ngtrans questions to Alain Durand <Alain.Durand@imag.fr>.
> 


-- 
--bill