[ppml] draft-ietf-ipv6-ula-central-02.txt use cases

Scott Leibrand sleibrand at internap.com
Thu Jun 28 01:41:59 EDT 2007

Paul Vixie wrote:
> From: Scott Leibrand <sleibrand at internap.com>
>> ... IMO, ULA-C is the best middle ground we have, and if the folks who think
>> it doesn't go far enough aren't willing to support a step in that direction,
>> then we'll just have to sit where we're at until there's enough demand for
>> liberalized PI.
> which ULA-C draft do you mean?  on june 21, IETF published ula-central-02 at
> <http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt> and
> it includes text about a 40-bit random number and permanent allocations without
> any need for renewal and any procedure for deallocation, and has instructions
> to IANA, with expectations that the RIRs will be the IANA's choice of operator
> for the "public database".  this doesn't sound like what you're in favour of.
> if what you think ought to be done is that FC::/7 should be reserved by IANA
> for non-DFZ use and that chunks like /16's ought to be handed to RIR's and
> /32's ought to be handed to LIR's and that RIR/LIR fee and qualification
> levels ought to be lower for this kind of space so that anyone who wants a
> /48 even if it's for their laptop ought to be able to get one and get IN-ADDR
> service and have the same WHOIS as normal PI... then you'll have to write that
> as an Internet Draft and submit it in competition to central-02.
> but i don't think you (scott liebrand) are in favour of central-02 as written
> and i know i'm not either.  so it's jarring to hear you say "ULA-C is the best
> middle ground we have".  the ULA-C on the table isn't the one you've advocated.

I much prefer the text you've proposed to that in 
draft-ietf-ipv6-ula-central-02.txt.  I also agree with you that the 
random permanent allocations are somewhat inconsistent with the need to 
maintain reverse DNS.  Thank you for suggesting better language, so I 
didn't have to.  I'd hate to see the results if I were to start 
designing header formats without help.  :-)


More information about the ARIN-PPML mailing list