Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy

[Thomas Narten <narten@us.ibm.com>]

Hi Stuart,

Thanks for the comments, and apologies that it took this long to
respond.

> 3.7.  Minimize Overhead

>      It is desirable to minimize the overhead associated with
>      obtaining additional address space as a site grows. Overhead
>      includes the need to go back to RIRs for additional space too
>      frequently, the overhead associated with managing address space
>      that grows through a number of small successive incremental
>      expansions rather than through fewer, but larger, expansions,
>      etc.

> This para talks about trying to minimize overhead as a site grows,
> but if a site is allocated a /48 and needs an additional /48 for
> expansion then according to 5.5.3 The LIR whose customers needs an
> additional /48 request needs to be reviewed at the RIR/NIR level.
> Is this really minimizing overhead!!  Maybe this section needs more
> text and a reference to 5.5.3?

I take it then that the goal is fine, but that the specific policy in
5.5.3 would appear at odds with this and may be too restrictive. Right?

I believe that the thinking here was that we at present haven't had
much discussion on when it is appropriate to allow an end site to have
more than a /48 (the current policy that is in place doesn't even
mention this possibility, as I recall). At the same time, there are
clearly cases where this would be appropriate. So the wording is a bit
of an attempt to make sure that allocations larger than a /48 get some
sort of review at least until we get experience with them. I would
expect that the review rules would be relaxed once there was some
experience with what kind of requests will get made.

Another approach would be to attempt to specify some of these
guidelines now. Any thoughts here on what they might look at, or some
sample text?

>      However, when a lease-license is renewed, the new lease-license
>      will be evaluated under and governed by the applicable resource
>      allocation and renewal policies in place at the time of
>      renewal.

> It is not clear what "resource allocation and renewal policies" are
> exactly.  There is no definition of them in this document.  Sounds
> like we are moving towards the way the DNS system works with the
> renewal of Domain Names.

The intent here was to allow the RIR policies to evolve over time
(i.e., as experience was gained) without previous policies in effect
preventing a new policy from being put into place because people feel
that address space assigned under an older policy is NOT subject to
the new policies (e.g., perhaps a higher utilization is needed in
order to request additional space, than was specified at the time the
allocation was originally made).

The other words in this section tried to put this in perspective, to
make clear that this was not something that would be done lightly, and
not without community input.

So, the intent is that renewals would normally be automatic, but that
future changes in the overall policies in effect might change that.

Does this make sense?

>   5.2.1.  Initial allocation criteria

>      A requesting organization can receive an initial allocation by
>      demonstrating that it has an immediate (i.e., within next three
>      months) requirement for at least a /36 prefix.  That is, immediately
>      after the allocation, the organization will have 776 or more sites in
>      need of address assignments.  776 is the number of /48 address  blocks
>      that can be assigned out of a /36 address block to achieve an HD-
>      Ratio of 0.8.  The HD-Ratio is an address allocation utilization
>      metric proposed in RFC 3194 as an adaptation of the H-Ratio
>      originally defined in [RFC1715].  (See also Section 5.3.3.)

>   This para now mention 3 months, but this is too short a time to 
> connect 776 customer sites. It is not obvious what the new time frame 
> should be, but it should be longer than 3 months.  I note that a 
> discussion is needed as below.

>      [Note: discussion is needed as to whether justification for need of  a
>      /36 is reasonable initial starting point, or whether the criteria of
>      an immediate need to address 776 sites is too high. Note also, that 
>      once a request for an initial allocation has been granted, the
>      minimum allocation (i.e., /32) is provided, even though the requestor
>      has not justified a need for such a large amount of space.]

The goal was to give a site a /32 if it can justify it will use
it. The word "immediately" (as in demonstrate an immediate need) is
clearly even worse, since it implies 0 months! The 3 month figure was
added because I understand that from the RIR perspective,
"immediately" doesn't actually mean literally immediately, and has in
practice meant something more like 3 months (I hope I got that right,
and it may actually vary from one region to another).

So the real issue here (and this comes up again in later parts of the
document) is what is a reasonable way to objectively evaluate a
request for address space that requires some guessing as to whether a
proposed plan will actually be carried out. If the time frame is too
long, it becomes easy to make optimistic plans that won't pan out, and
then the RIRs get into a different problem.

Thoughts here? Is the 3 month time too short (what would be better)?

Sould it be 2 years, as is proposed in the section on subsequent
allocations? Why or why not?

Or is it the 776 end site figure (i.e., too high)?

>   5.2.2.  Initial allocation size

>      A requesting organization satisfying the initial allocation  criteria
>      can receive an initial allocation of the minimum /32 address block. 
>      Any organization requesting a larger address block may receive the
>      necessary size of allocation by submitting documentation that
>      reasonably justifies the necessity.  For instance, a provider or an 
>      enterprise currently providing IPv4 address services may apply for
>      and receive an initial allocation of the size reasonably judged
>      necessary to provide all the existing users with IPv6 services. In
>      this case, the necessary size will be judged on the basis of the
>      number of existing users and infrastructure.

>   Shouldn't this be that the IPv4 provider should be allocated an 
> initial allocation for its IPv4 customers PLUS the next 2 years growth, 
> as in 5.3.4. Otherwise we will have the scenario where an IP v4 provider 
> switches to IPv6, and changes its customers over to IPv6 and then has to 
> go back to the RIR to request an additional block for its new IPv6 
> customers.  Suggest that the "2 year rule" should be applied here also.

An interesting suggestion. One way to view the two-year rule is that
on *subsequent* allocations, an LIR has a track record *with* IPv6 and
that should count for something (i.e., look towards the next two years
of planned growth). For an IPv4 provider converting to IPv6, is it
reasonable to do the same?

Thoughts? 

>   5.4.  LIR-to-ISP allocation

>      There is no specific policy for an organization (ISP/LIR) to
>      allocate address space to subordinate ISPs.  Each LIR
>      organization may develop its own policy for subordinate ISPs to
>      encourage optimum utilization of the total address block
>      allocated to the LIR. However, the LIR is required to keep
>      track of all /48s assignments, including assignments made by
>      its subordinate ISPs to end users, and report the assignment
>      status to RIR/NIR so that the HD-Ratio can be evaluated when a
>      subsequent allocation becomes necessary.

>   Here the text implies that the LIR should keep track of all
> subordinate allocations, which means that if an LIR allocates a
> block to a subordinate ISP then the LIR needs to keep track of all
> the /48s that the subordinate ISP allocates to its own customers.
> Then, when the LIR requests a larger allocation, that same LIR needs
> to report these allocations to RIR/NIR so that the RIR/NIR can then
> calculate the subsequent allocation.  However, earlier in "3.3.
> Registration" it says that "Every assignment and allocation of
> Internet address space must be registered in a public registry
> database accessible to all members of the Internet community"

>   Also the text says "and report the assignment status to RIR/NIR so
> that the HD-Ratio can be evaluated" which implies to me that the
> /48s allocated by the subordinate ISP are not in a public
> database. It also talks about registration in 5.6 see below.  This
> registration question needs clarifying - as the document contradicts
> itself.

I think that the basic goal is simply that the utilization of /48s can
be verified. 

>   I suggest all LIR allocations and subordinate allocations from the LIR 
> be registered, as these will be a large e.g. /32, /40?.  Then if the 
> subordinate ISP of the LIR allocates /48's these can either be in the 
> seen in the RIR/NIR database or kept in it's own or LIR database which 
> is private.  When a LIR requests a subsequent allocation to reports 
> assignments to RIR/NIR from the LIRs own records & subordinate records.

>   Currently in IPv4, addresses are registered in either a public
> database or in the LIR's own database, thus allowing a
> mixture. Thus, if we need to keep our customer information private,
> we can keep it "off" a public database, but if the customers network
> does want to be seen in the public database then we can enter it.
> Suggest the same principle needs to be applied to IPv6 as with IPv4
> allocations today, and only down to the /48 level.  The ISP may keep
> it's own records of /48s /64's & /128s, but it is upto the LIR what
> depth it records down to after the /48 level.

Makes sense to me. As far as I know, there is no intention to be
different relative to IPv4 in terms of who is required to record
information about allocation.

>   5.6.  DB registration

>      When an organization in reciept of an IPv6 address allocation
>      makes IPv6 address assignments, it must register assignment
>      information in a public database (initially a database
>      maintained by an RIR/NIR, which may be replaced by a
>      distributed database for registering address management
>      information in future).  Information is registered in units of
>      assigned /48 networks.  When an organization assigns an
>      address space larger than a /48 to another organization, it
>      must monitor if this organization has registered address
>      utilization information in a public database.

>   This para talks about an organization (LIR) assigning an address
> space larger than a /48 to another organization.  In this case it
> implies that the other organization (NOT THE LIR) must register its
> /48's in a public database and that the LIR must ensure that the
> other organization has done this.  But section 3.3 implies that
> every allocation be an a public database, and section 5.4 implies
> that it is not.

yes. a contradiction.

I would assume that the section 3.3 text, saying everything must be
recorded publically, is what should be changed. I.e., if this is not
what is done in IPv4 today, why should we be doing so for IPv6?

Comments?

Thomas

-
- This list (global-v6) is handled by majordomo@lists.apnic.net