[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. :-)
-Scott
More information about the ARIN-PPML
mailing list