[apnic-talk] Re: [ipv6-wg@ripe.net] RE: [address-policy-wg] Re: IANAto RIR ipv6 Allocation

[Jeff Williams <jwkckid1@ix.netcom.com>]

Iljitsch and all,

  None of this addresses the outstanding problems with Ipv6 or ipv6
allocation concerns and existing as well as discussed problems.
They are "at least" the following:
1. ) Invalid or incorrect minimal allocation.
2.) Still existing cost increases for allocations.
3.) Still existing security/privacy "holes" in ipv6
4.) Routing notification for new allocation practice or method.
5.) Routing table maintenance Best practices and/or policy, and enforcement
     of same.
6.) Dealing with "Dark" existing and/or future allocated addresses.

Iljitsch van Beijnum wrote:

> On 20-aug-04, at 14:01, Ray Plzak wrote:
>
> > Wilfried,
>
> > I've forwarded your comment to the ARIN ppml.
>
> Ray, as long as you're forwarding, maybe you'll find my comment to the
> RIPE list from a week and a half ago of interest:
>
> > The Number Resource Organisation (NRO) has published a proposal for a
> > policy for the allocation of IPv6 address space from the IANA to the
> > RIRs. It is intended that this proposed policy should be agreed by all
> > RIRs' open policy fora and then approved by the ASO and ICANN as a
> > global policy.
>
> Reserving a /6 for each RIR seems like the other extreme to me. In IPv4
> we have around 220 /8s that have been given out to RIRs pretty much one
> at a time in the past. In IPv6 we effectively have 8 /6s. This means
> that as a percentage of total available space, the RIRs get more than
> 25 times more IPv6 space than they've been given IPv4 space in the
> past, even though a v4 /8 will accommodate at most 16.8M end-user
> assignments (less in practice) while a v6 /6 allows for AT LEAST 4.4T
> (yes, that's 10^12) end-user assignments.
>
> Now I can see SOME value in trying to have relatively large RIR blocks,
> but cutting up all non-reserved space so aggressively really doesn't
> have any upsides, and we never know whether we're going to need any
> really large blocks in the future. Also, doubling every time is ok for
> a while, but it pretty much guarantees that you're going to have way
> too much space on your hands at some point.
>
> A more reasonable policy would be:
>
> - reserve a /12 for each RIR now (a 4 bit boundary makes DNS
> delegations easier, I think a /8 is too much but that might work also)
> - then, for every delegation, give RIRs enough space to each to last a
> year comfortably
> - evaluate whether a new delegation is needed every 3 or 4 months,
> making the time of new delegations easy to predict

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1@ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827