[arin-ppml] ARIN-PPML Digest, Vol 94, Issue 3
MsRachelleCross/GM
msrachellecross at gmail.com
Wed Apr 3 14:56:10 EDT 2013
Good afternoon, pardon me, I've been a little under the weather; if someone could clarify for me; am I correct in understanding that some ARIN protocol
is being re-drafted? If so, long overdue, and much needed.
While this proposal appears to focus on
IPv6 block protocol, Mr. Ross sufficiently
inculcates that even though some organizations will have multiple IPv6 blocks, obtained through subsequent allocations or assignments where an existing block could not be adequately expanded or competently managed;
It is my belief these situations occur already. Even with IPv6 in place, many hosts are finding difficulty protecting their servers and clients because even hackers have found ways to infiltrate the IPv6 system.
In re-establishing draft protocol, I hope we can work out a system of checks and balances, and accountability for such cybercrimes.
Additionally, Those registrants with so many IPs? If an audit were done, how many of those IP's are truly theirs by legal acquisition?
We are ARIN. Therefore, it's our jobs to ensure safety on the Internet. I personally know of several IP hosts who have violated intellectual genre, and (c) laws, having taken over people's Domains after providing service. There are other people out here who's entire IPv6 networks get hacked. People have related stories of losing information off of all their computers, mainframe, and all software licenses.
Sirs, will any of the new protocol protect innocent everyday people, making the Internet safe for everyone, and not just those of us with technical knowledge?
I would very much appreciate an opportunity to work with your team if I can be of assistance.
Namaste,
Rev Rachelle C.Navarro
PhD, MS
On Apr 3, 2013, at 0:11, arin-ppml-request at arin.net wrote:
> Send ARIN-PPML mailing list submissions to
> arin-ppml at arin.net
>
> 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
> arin-ppml-request at arin.net
>
> You can reach the person managing the list at
> arin-ppml-owner at arin.net
>
> 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 <farmer at umn.edu>
> To: Brandon Ross <bross at pobox.com>
> Cc: John Curran <jcurran at arin.net>, ARIN PPML <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
> Allocations for ISPs
> Message-ID: <515B68AE.4080906 at umn.edu>
> 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: farmer at umn.edu
> 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 <owen at delong.com>
> To: David Farmer <farmer at umn.edu>
> Cc: John Curran <jcurran at arin.net>, ARIN PPML <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
> Allocations for ISPs
> Message-ID: <0BDA5B2D-09B6-47C5-8CBF-E3B2315A0551 at delong.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Apr 2, 2013, at 16:24 , David Farmer <farmer at umn.edu> 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 <farmer at umn.edu>
> To: Owen DeLong <owen at delong.com>
> Cc: John Curran <jcurran at arin.net>, ARIN PPML <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
> Allocations for ISPs
> Message-ID: <515BB740.3000602 at umn.edu>
> 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 <farmer at umn.edu> 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: farmer at umn.edu
> 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 <owen at delong.com>
> To: David Farmer <farmer at umn.edu>
> Cc: John Curran <jcurran at arin.net>, ARIN PPML <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
> Allocations for ISPs
> Message-ID: <3E2E8083-7C91-474E-87CE-42E6B90E3D49 at delong.com>
> Content-Type: text/plain; charset=iso-8859-1
>
>
> On Apr 2, 2013, at 9:59 PM, David Farmer <farmer at umn.edu> wrote:
>
>> On 4/2/13 19:58 , Owen DeLong wrote:
>>> On Apr 2, 2013, at 16:24 , David Farmer <farmer at umn.edu> 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
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 94, Issue 3
> ****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130403/8651442a/attachment.htm>
More information about the ARIN-PPML
mailing list