[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
Hello Thomas,
Thanks for your reply, I have commented in-line blow,
Regards,
Stuart
----- Original Message -----
From: "Thomas Narten" <narten@us.ibm.com>
To: "Stuart Prevost" <stuart.prevost@btinternet.com>
Cc: <global-v6@lists.apnic.net>
Sent: Friday, February 01, 2002 7:50 PM
Subject: Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and
Assignment Global Policy
> 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?
The goal to minimize overhead I agree with, but as you said 5.5.3 is at odds
with the concept of minimizing overheads.
>
> 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?
>
I would personally allow the LIR to be responsible for the allocations
larger than a /48. So say a company requires more than one /48, say it
needs a /47. Then I would argue that it is upto the LIR to review and
approve this allocation itself. The LIR at the end of the day will be
responsible for 64k /48s so why not allow it to decide if the customer needs
a /47 or not.
> > 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?
It does know, and make good sense to leave it open for the future.
>
> > 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)?
>
Losts of questions, but intial thoughts here are to add a section in the
document specifing that IPv6 address allocations that aren't used WILL be
reclaimed after a certain period of time. If I remember correctly such a
approach is currently specified in RIPE-196(4.2.1b). I suggest that if
people are worried about the length of time to deploy as myself in this
document, why not say if you don't use within a 2 year period (for
example)then they are subject to being returned. This way we could move the
argument away from number of intial sites to get a /32, and hopefully advoid
cyber squatting on address space, so if addresses aren't used based on the
initial plans that a LIR presents to the RIR then the RIR should reclaim.
> > 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?
Thomas sorry I don't understand your point. I feel that a IPv4 provider
converting to IPv6 should get the equivilant IPv6 address allocation for his
IPv4 network/customer + the next 2 year rule.
>
> > 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?
Totally agree,
Thanks for your comments and I hope you find my replies usefull. I look
forward to a more e-mails on the list.
Best regards,
Stuart
>
> Thomas
>
> -
> - This list (global-v6) is handled by majordomo@lists.apnic.net
>
-
- This list (global-v6) is handled by majordomo@lists.apnic.net
