Send ARIN-PPML mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(David Farmer)
2. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Owen DeLong)
3. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(David Farmer)
4. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Owen DeLong)
----------------------------------------------------------------------
Message: 1
Date: Tue, 02 Apr 2013 18:24:30 -0500
From: David Farmer <[email protected]>
To: Brandon Ross <[email protected]>
Cc: John Curran <[email protected]>, ARIN PPML <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 3/30/13 18:06 , Brandon Ross wrote:
> On Fri, 29 Mar 2013, David Farmer wrote:
>
>> After thinking about it for a while, if we even need any policy at
>> all, we should just have a general policy describing how IPv6 block
>> can be reduced by returning only part of a block, it should probably
>> be very generic and apply to allocations and end user assignments. It
>> might even be better if it we a separate proposal all together.
>
> Agreed, which is why the language in this proposal allows for that, and
> that was done on purpose.
>
> I don't want to see that separated to a separate policy proposal because
> it is critical to making this one function as intended.
Well, yes and no, John has already fix the operational issue, the only
effect your proposed text would have at the moment would be to restrict
it to the first or last blocks of the larger original block.
This raise a question for me do we really need to restrict it to the
first or last blocks? Personal, I'm ok with allowing the person making
the return to have the flexibility to make choice of any contiguous and
alined /40 out of the /32 they want.
Next, I'm thinking about a new subsection;
6.12 Reduction or Return
Organizations may return all or part of their allocations or
assignments, that are not in use, to ARIN at any time with the
following considerations;
a. Such a return or reduction must not result in a larger number of
blocks being held by an organization, if possible fewer blocks
are preferred.
b. If a whole block is not in use, the whole block should be
returned to ARIN.
c. If part of a block is returned; A single contiguous nibble
alined block, no smaller than the applicable minimum block size
allowed by policy, should be selected and retained by the
organization. The remainder of the original block must not be
in use and must be returned to ARIN. It is possible for
multiple separate blocks to be retained from a single original
block as long as clause (a) above is also meet.
This is very generic covering both ISP/LIR allocations and end user
assignments. The basic concept is that returns can't create additional
block that will negatively impact aggregation. And with partial returns
the retained portion must be a nibble alined and no smaller than policy
allows.
Also, related to this I'd like to delete section 6.5.8.4 "Consolidation
and return of separate assignments", delete the last sentence of 6.5.3
clause (c), and add a new subsection in 6.3 "Goals of IPv6 address space
management";
6.3.9 Consolidation and return
Some organization will have multiple IPv6 blocks, obtained through
subsequent allocations or assignments where an existing block could
not be sufficiently expanded, or through transfers (mergers and
acquisitions). Such organizations should consider consolidating to
a single block, or at least minimizing the number of blocks used
for new sub-assignments. This should not be considered a
recommendation for large-scale active renumbering out of blocks at
are in use. To the contrary, such consolidation is merely a goal
and would likely occur over several years. Further, it should
primarily be achieved through attrition and other normal
operational change. Finally, return of a block is expected once it
is no longer in active use.
Moving the issue of consolidation to goals cleans up the subsequent
allocation and assignment sections. It is intended to provide goals,
motivation and some direction regarding why someone might want to return
addresses. Putting it in the goals section prevents it from being
confused with the issues of making subsequent allocations and
assignments or the new Reduction or Return section above.
This is why I was thinking about a separate proposal, because I think
the consolidation issue is more closely linked to the return and
reduction section than with the x-small and xx-small fee category issues.
What do others think?
--
================================================
David Farmer Email: [email protected]
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================
------------------------------
Message: 2
Date: Tue, 2 Apr 2013 17:58:02 -0700
From: Owen DeLong <[email protected]>
To: David Farmer <[email protected]>
Cc: John Curran <[email protected]>, ARIN PPML <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Apr 2, 2013, at 16:24 , David Farmer <[email protected]> wrote:
> On 3/30/13 18:06 , Brandon Ross wrote:
>> On Fri, 29 Mar 2013, David Farmer wrote:
>>
>>> After thinking about it for a while, if we even need any policy at
>>> all, we should just have a general policy describing how IPv6 block
>>> can be reduced by returning only part of a block, it should probably
>>> be very generic and apply to allocations and end user assignments. It
>>> might even be better if it we a separate proposal all together.
>>
>> Agreed, which is why the language in this proposal allows for that, and
>> that was done on purpose.
>>
>> I don't want to see that separated to a separate policy proposal because
>> it is critical to making this one function as intended.
>
> Well, yes and no, John has already fix the operational issue, the only effect
> your proposed text would have at the moment would be to restrict it to the
> first or last blocks of the larger original block.
>
> This raise a question for me do we really need to restrict it to the first or
> last blocks? Personal, I'm ok with allowing the person making the return to
> have the flexibility to make choice of any contiguous and alined /40 out of
> the /32 they want.j
Since we're holding (at least) the /32 in reserve for them anyway and ideally
the /28, I really don't think it matters which /40 they're using.
>
> Next, I'm thinking about a new subsection;
>
> 6.12 Reduction or Return
>
> Organizations may return all or part of their allocations or
> assignments, that are not in use, to ARIN at any time with the
> following considerations;
>
> a. Such a return or reduction must not result in a larger number of
> blocks being held by an organization, if possible fewer blocks
> are preferred.
>
> b. If a whole block is not in use, the whole block should be
> returned to ARIN.
>
> c. If part of a block is returned; A single contiguous nibble
> alined block, no smaller than the applicable minimum block size
> allowed by policy, should be selected and retained by the
> organization. The remainder of the original block must not be
> in use and must be returned to ARIN. It is possible for
> multiple separate blocks to be retained from a single original
> block as long as clause (a) above is also meet.
I think this vastly overcomplicates what should be relatively simple...
How about this:
6.12 Reduction or Return
ARIN will accept any return which allows an LIR to reduce their
holdings to fit a lower tier in the fee schedule so long as:
1. The end result is not an increase in the number of
non-contiguous blocks held by the LIR.
2. Whole blocks are returned to the extent practicable.
3. Retained block(s) are within the largest reserved space
set aside for the LIR in the ARIN database to the extent
practicable.
I think it is better to express directly what it is that we want to happen
in general terms and trust that ARIN and the LIRs will generally find
a way to do the right thing so long as we do not prevent them from
doing so.
> Also, related to this I'd like to delete section 6.5.8.4 "Consolidation and
> return of separate assignments", delete the last sentence of 6.5.3 clause
> (c), and add a new subsection in 6.3 "Goals of IPv6 address space management";
>
> 6.3.9 Consolidation and return
>
> Some organization will have multiple IPv6 blocks, obtained through
> subsequent allocations or assignments where an existing block could
> not be sufficiently expanded, or through transfers (mergers and
> acquisitions). Such organizations should consider consolidating to
> a single block, or at least minimizing the number of blocks used
> for new sub-assignments. This should not be considered a
> recommendation for large-scale active renumbering out of blocks at
> are in use. To the contrary, such consolidation is merely a goal
> and would likely occur over several years. Further, it should
> primarily be achieved through attrition and other normal
> operational change. Finally, return of a block is expected once it
> is no longer in active use.
I think this is unnecessary and that the concerns driving this can be better
addressed through improved operational practice.
Owen
------------------------------
Message: 3
Date: Tue, 02 Apr 2013 23:59:44 -0500
From: David Farmer <[email protected]>
To: Owen DeLong <[email protected]>
Cc: John Curran <[email protected]>, ARIN PPML <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 4/2/13 19:58 , Owen DeLong wrote:
> On Apr 2, 2013, at 16:24 , David Farmer <[email protected]> wrote:
>> Next, I'm thinking about a new subsection;
>>
>> 6.12 Reduction or Return
>>
>> Organizations may return all or part of their allocations or
>> assignments, that are not in use, to ARIN at any time with the
>> following considerations;
>>
>> a. Such a return or reduction must not result in a larger number of
>> blocks being held by an organization, if possible fewer blocks
>> are preferred.
>>
>> b. If a whole block is not in use, the whole block should be
>> returned to ARIN.
>>
>> c. If part of a block is returned; A single contiguous nibble
>> alined block, no smaller than the applicable minimum block size
>> allowed by policy, should be selected and retained by the
>> organization. The remainder of the original block must not be
>> in use and must be returned to ARIN. It is possible for
>> multiple separate blocks to be retained from a single original
>> block as long as clause (a) above is also meet.
>
> I think this vastly overcomplicates what should be relatively simple...
>
> How about this:
>
> 6.12 Reduction or Return
>
> ARIN will accept any return which allows an LIR to reduce their
> holdings to fit a lower tier in the fee schedule so long as:
>
> 1. The end result is not an increase in the number of
> non-contiguous blocks held by the LIR.
>
> 2. Whole blocks are returned to the extent practicable.
>
> 3. Retained block(s) are within the largest reserved space
> set aside for the LIR in the ARIN database to the extent
> practicable.
>
> I think it is better to express directly what it is that we want to happen
> in general terms and trust that ARIN and the LIRs will generally find
> a way to do the right thing so long as we do not prevent them from
> doing so.
First, my intent was to use "organization" rather than "LIR" as I wanted
it to be general and apply to both LIRs and end users, that is also why
I moved it out to 6.12. Do you believe only LIR might wnat to reduce
their holdings? You were advocating that end user annual fee be scaled
to holding too, do you want to change the policy when that happens? Let
keep it general and use "organization"
Second, in your #3, what do the retained block(s) have to do with the
reserved space? The retained block(s) are the block(s) kept by the
organization and the reserved space is an ARIN operational issue. I
believe we want the retained block(s) nibble aligned and no smaller than
allowed by policy, /40 for an LIR and /48 for an end user. However, it
would be better not to specify the minimums and get as a reference to
applicable policy.
Do you want to allow non-nibble alined blocks to be retained? If you do
then why not just allocate them in the first place.
Or, am I missing something?
--
================================================
David Farmer Email: [email protected]
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================
------------------------------
Message: 4
Date: Tue, 2 Apr 2013 22:08:35 -0700
From: Owen DeLong <[email protected]>
To: David Farmer <[email protected]>
Cc: John Curran <[email protected]>, ARIN PPML <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Apr 2, 2013, at 9:59 PM, David Farmer <[email protected]> wrote:
> On 4/2/13 19:58 , Owen DeLong wrote:
>> On Apr 2, 2013, at 16:24 , David Farmer <[email protected]> wrote:
>>> Next, I'm thinking about a new subsection;
>>>
>>> 6.12 Reduction or Return
>>>
>>> Organizations may return all or part of their allocations or
>>> assignments, that are not in use, to ARIN at any time with the
>>> following considerations;
>>>
>>> a. Such a return or reduction must not result in a larger number of
>>> blocks being held by an organization, if possible fewer blocks
>>> are preferred.
>>>
>>> b. If a whole block is not in use, the whole block should be
>>> returned to ARIN.
>>>
>>> c. If part of a block is returned; A single contiguous nibble
>>> alined block, no smaller than the applicable minimum block size
>>> allowed by policy, should be selected and retained by the
>>> organization. The remainder of the original block must not be
>>> in use and must be returned to ARIN. It is possible for
>>> multiple separate blocks to be retained from a single original
>>> block as long as clause (a) above is also meet.
>>
>> I think this vastly overcomplicates what should be relatively simple...
>>
>> How about this:
>>
>> 6.12 Reduction or Return
>>
>> ARIN will accept any return which allows an LIR to reduce their
>> holdings to fit a lower tier in the fee schedule so long as:
>>
>> 1. The end result is not an increase in the number of
>> non-contiguous blocks held by the LIR.
>>
>> 2. Whole blocks are returned to the extent practicable.
>>
>> 3. Retained block(s) are within the largest reserved space
>> set aside for the LIR in the ARIN database to the extent
>> practicable.
>>
>> I think it is better to express directly what it is that we want to happen
>> in general terms and trust that ARIN and the LIRs will generally find
>> a way to do the right thing so long as we do not prevent them from
>> doing so.
>
> First, my intent was to use "organization" rather than "LIR" as I wanted it
> to be general and apply to both LIRs and end users, that is also why I moved
> it out to 6.12. Do you believe only LIR might wnat to reduce their holdings?
> You were advocating that end user annual fee be scaled to holding too, do
> you want to change the policy when that happens? Let keep it general and use
> "organization"
>
s/LIR/organization/g is fine by me.
I believe that only LIRs can reduce their charge tier by returning partial
blocks. To save money an end-user would have to return an entire block and
that's already permitted by existing policy elsewhere.
> Second, in your #3, what do the retained block(s) have to do with the
> reserved space? The retained block(s) are the block(s) kept by the
> organization and the reserved space is an ARIN operational issue. I believe
> we want the retained block(s) nibble aligned and no smaller than allowed by
> policy, /40 for an LIR and /48 for an end user. However, it would be better
> not to specify the minimums and get as a reference to applicable policy.
That's fine, but orthogonal to #3. My intent is to make sure that if they
expand back to larger, their existing retained blocks are not from disparate
reservations scattered throughout IPv6 and rather that they can expand into
their single reservation. At least to the extent practicable.
> Do you want to allow non-nibble alined blocks to be retained? If you do then
> why not just allocate them in the first place.
No. I figured existing policy pretty well covered that elsewhere, but I'm happy
to add that provision.
How about:
4. All retained blocks shall fall on nibble-aligned boundaries.
Owen
>
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 94, Issue 3
****************************************
