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. Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy (ARIN)
2. Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs (ARIN)
3. Re: Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy
(Scott Leibrand)
4. Re: Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy
(William Herrin)
5. Re: Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy
(Michael Richardson)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Mar 2013 14:20:27 -0400
From: ARIN <[email protected]>
To: [email protected]
Subject: [arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP
Resource Policy
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Draft Policy ARIN-2013-2
3GPP Network IP Resource Policy
On 21 March 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-184
3GPP Network IP Resource Policy" as a Draft Policy.
Draft Policy ARIN-2013-2 is below and can be found at:
https://www.arin.net/policy/proposals/2013_2.html
You are encouraged to discuss the merits and your concerns of Draft
Policy 2013-2 on the Public Policy Mailing List. 2013-2 will also be on
the agenda at the upcoming ARIN Public Policy Meeting in Barbados. The
AC will evaluate the discussion in order to assess the conformance of
this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:
* Enabling Fair and Impartial Number Resource Administration
* Technically Sound
* Supported by the Community
The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
Regards,
Communications and Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Draft Policy ARIN-2013-2
3GPP Network IP Resource Policy
Date: 27 March 2013
Problem Statement:
Current 3GPP architectures consist of hierarchical aggregation, from
cell site up to anchor nodes, approximately one per NFL city. Anchor
nodes are the point where IP addresses are assigned and topologically
positioned in the network. Generally an anchor node must be provisioned
with enough addresses to handle all simultaneously attached users, plus
enough headroom to handle failover from an adjacent anchor node in the
event of an outage. Capacity planning generally ensures that all anchor
nodes have approximately the same number of attached users at steady
state. Moving addresses between anchor nodes would require significant
renumbering effort and substantial increases in operational complexity,
so cannot be performed during an outage. Generally addresses are not
renumbered between anchor nodes: instead, aggregation nodes can be
rehomed as needed to balance steady state capacity levels. Because of
the 3GPP architecture's failover and capacity planning requirements, all
cellular networks target approximately 50% simultaneous usage of each
anchor node's IP addresses. However, even at 50% usage, the total number
of subscribers generally exceeds the number of addresses needed.
Currently, a number of mobile networks are using non-RIR-assigned space
internally to meet customer demand. However, there is insufficient
private space (RFC1918, etc.) available for internal use, so other
unassigned space is currently being used. As this unassigned space is
brought into service via reclamation, returns, and transfers, it is no
longer possible to use it internally, so globally unique space must be
used instead. As a result, most of the need for additional RIR-assigned
space is to serve existing customers, not to accommodate future growth.
Policy statement:
I can see two possible approaches to address this need. One approach
would be to continue counting simultaneously attached users to measure
IP needs, and apply a 50% usage requirement to justify allocations.
Another approach would be to instead count total subscribers (rather
than simultaneously attached users), and apply a much higher threshold,
such as 80% or even 90%, to justify allocations.
Timetable for implementation: ASAP
------------------------------
Message: 2
Date: Wed, 27 Mar 2013 14:20:46 -0400
From: ARIN <[email protected]>
To: [email protected]
Subject: [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
Draft Policy ARIN-2013-3
Tiny IPv6 Allocations for ISPs
On 21 March 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-185
Tiny IPv6 Allocations for ISPs" as a Draft Policy.
Draft Policy ARIN-2013-3 is below and can be found at:
https://www.arin.net/policy/proposals/2013_3.html
You are encouraged to discuss the merits and your concerns of Draft
Policy 2013-3 on the Public Policy Mailing List. 2013-3 will also be on
the agenda at the upcoming ARIN Public Policy Meeting in Barbados. The
AC will evaluate the discussion in order to assess the conformance of
this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:
* Enabling Fair and Impartial Number Resource Administration
* Technically Sound
* Supported by the Community
The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
Regards,
Communications and Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Draft Policy ARIN-2013-3
Tiny IPv6 Allocations for ISPs
Date: 27 March 2013
Problem Statement:
ARIN's fee structure provides a graduated system wherein organizations
pay based on the amount of number resources they consume.
At the very bottom end of the scale, it is presently not possible to be
an XX-Small ISP with an IPv6 allocation because the minimum allocation
size of /36 automatically promotes one into Small ISP status, resulting
in a doubling of annual fees.
While tiny in absolute terms, the extra costs incurred represent a
disincentive to IPv6 deployment.
To the author's knowledge, it has never been possible for an LIR/ISP to
get a /48 allocation direct from ARIN; assignments of /48s have been
limited to organizations that qualify as end sites or critical
infrastructure.
Policy statement:
Part 1: In the NRPM, change 6.5.2.1(b) from:
In no case shall an LIR receive smaller than a /32 unless they
specifically request a /36. In no case shall an ISP receive more than a
/16 initial allocation.
to:
In no case shall an LIR receive smaller than a /32 unless they
specifically request a /36 or a /48. In no case shall an ISP receive
more than a /16 initial allocation.
Part 2: In the NRPM, append a subsection to 6.5:
An LIR may return all or part of an allocation to ARIN, however if the
LIR retains a portion, the aggregate retained must be either the first
(lowest numbered) subnet of that prefix or the largest (highest
numbered) subnet of the returned block. The smallest prefix that may be
retained by the LIR shall be no smaller than the smallest prefix that
may be allocated under current policy at the time of the address space
return.
Comments:
The author acknowledges the shortcomings of providing an ISP with an
allocation of a size that is more traditionally associated with end
sites. In order to avoid possible bad effects on the routing table, the
author encourages ARIN staff to adopt the same sparse allocation
practice as currently exists for larger allocations, perhaps even
reserving a block as large as the /28 that is reserved for /32s.
Part 1 brings ARIN's allocation policies in line with the upcoming fee
schedule so that it is possible to qualify as every level of ISP while
holding IPv6 number resources.
Part 2 codifies and expands upon current practice for selective return
in the manner described by John Curran on the arin-discuss mailing list
(7-Mar-2013 in
[email protected] )
A more practical approach might to figure out a way to apply graduated
fees to ISPs at the very small end of the scale using some metric other
than prefix size. Fee schedules are outside of the purview of the Public
Policy Process; such responsibility lies with the Board should they
choose to take it up.
Timetable for implementation: Immediate
------------------------------
Message: 3
Date: Wed, 27 Mar 2013 11:32:24 -0700
From: Scott Leibrand <[email protected]>
To: ARIN <[email protected]>
Cc: ARIN-PPML List <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP
Resource Policy
Message-ID:
<cagkmwz5guw2lztnn+r3ete6uepgte1blqnoanjjrv5ywaif...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
As one of the AC shepherds for the policy, I am hoping to have a
discussion, both here on PPML at at the upcoming ARIN meeting, to cover a
few key points:
- Is the problem statement clear to the community? Do you have any
questions on the problem the proposal is attempting to solve?
- Do you feel that it is an important problem to try to solve? Do you
have any reasons you can share that we should or shouldn't do so?
- If so, how would you prefer we approach solving it? Some suggestions
are outlined in the proposal below, but we'll need to decide on an approach
and write and discuss actual policy text in order to move this Draft Policy
forward. This proposal will *not* be eligible for last call after ARIN 31
in Barbados, but we will be discussing it there.
So if you have any input now, please speak up. We'll be locking down the
version of the Draft Policy that will be printed in the ARIN 31 discussion
guides by April 5th, so please provide any input you can before then.
Thanks,
Scott
On Wed, Mar 27, 2013 at 11:20 AM, ARIN <[email protected]> wrote:
> Draft Policy ARIN-2013-2
> 3GPP Network IP Resource Policy
>
> On 21 March 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-184
> 3GPP Network IP Resource Policy" as a Draft Policy.
>
> Draft Policy ARIN-2013-2 is below and can be found at:
> https://www.arin.net/policy/**proposals/2013_2.html<https://www.arin.net/policy/proposals/2013_2.html>
>
> You are encouraged to discuss the merits and your concerns of Draft Policy
> 2013-2 on the Public Policy Mailing List. 2013-2 will also be on the agenda
> at the upcoming ARIN Public Policy Meeting in Barbados. The AC will
> evaluate the discussion in order to assess the conformance of this draft
> policy with ARIN's Principles of Internet Number Resource Policy as stated
> in the PDP. Specifically, these principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
> The ARIN Policy Development Process (PDP) can be found at:
> https://www.arin.net/policy/**pdp.html<https://www.arin.net/policy/pdp.html>
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/**proposals/index.html<https://www.arin.net/policy/proposals/index.html>
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy ARIN-2013-2
> 3GPP Network IP Resource Policy
>
> Date: 27 March 2013
>
> Problem Statement:
>
> Current 3GPP architectures consist of hierarchical aggregation, from cell
> site up to anchor nodes, approximately one per NFL city. Anchor nodes are
> the point where IP addresses are assigned and topologically positioned in
> the network. Generally an anchor node must be provisioned with enough
> addresses to handle all simultaneously attached users, plus enough headroom
> to handle failover from an adjacent anchor node in the event of an outage.
> Capacity planning generally ensures that all anchor nodes have
> approximately the same number of attached users at steady state. Moving
> addresses between anchor nodes would require significant renumbering effort
> and substantial increases in operational complexity, so cannot be performed
> during an outage. Generally addresses are not renumbered between anchor
> nodes: instead, aggregation nodes can be rehomed as needed to balance
> steady state capacity levels. Because of the 3GPP architecture's failover
> and capacity planning requirements, all cellular networks target
> approximately 50% simultaneous usage of each anchor node's IP addresses.
> However, even at 50% usage, the total number of subscribers generally
> exceeds the number of addresses needed.
>
> Currently, a number of mobile networks are using non-RIR-assigned space
> internally to meet customer demand. However, there is insufficient private
> space (RFC1918, etc.) available for internal use, so other unassigned space
> is currently being used. As this unassigned space is brought into service
> via reclamation, returns, and transfers, it is no longer possible to use it
> internally, so globally unique space must be used instead. As a result,
> most of the need for additional RIR-assigned space is to serve existing
> customers, not to accommodate future growth.
>
> Policy statement:
>
> I can see two possible approaches to address this need. One approach would
> be to continue counting simultaneously attached users to measure IP needs,
> and apply a 50% usage requirement to justify allocations. Another approach
> would be to instead count total subscribers (rather than simultaneously
> attached users), and apply a much higher threshold, such as 80% or even
> 90%, to justify allocations.
>
> Timetable for implementation: ASAP
> ______________________________**_________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/**listinfo/arin-ppml<http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact [email protected] if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130327/53ba4e36/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 27 Mar 2013 15:41:39 -0400
From: William Herrin <[email protected]>
To: Scott Leibrand <[email protected]>
Cc: ARIN-PPML List <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP
Resource Policy
Message-ID:
<CAP-guGUy71K8J=NK+C9NVGHjta3jqhhiYjNVaBQ=emg+mdu...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Mar 27, 2013 at 2:32 PM, Scott Leibrand <[email protected]> wrote:
> As one of the AC shepherds for the policy, I am hoping to have a discussion,
> both here on PPML at at the upcoming ARIN meeting, to cover a few key
> points:
>
> - Is the problem statement clear to the community?
Yes. Existing software limitations make it difficult to impossible to
run a reliable 3GPP network at greater than around 40% utilization of
addresses versus connected subscribers. Current ARIN standards require
80% (?) utilization.
> - Do you feel that it is an important problem to try to solve?
Yes.
> - If so, how would you prefer we approach solving it?
Dual stack: IPv4 CGN plus IPv6.
This problem is not unique to 3GPP architectures. Virtually every
eyeball network has a version this problem with similarly scoped
technical limitations. The ship sailed on solving it with more IPv4
addresses years ago. What's "special" here that makes it any different
from everybody else's unmet need?
Regards,
Bill Herrin
--
William D. Herrin ................ [email protected] [email protected]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
------------------------------
Message: 5
Date: Wed, 27 Mar 2013 15:35:32 -0400
From: Michael Richardson <[email protected]>
To: ARIN-PPML List <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP
Resource Policy
Message-ID: <[email protected]>
>>>>> "Scott" == Scott Leibrand <[email protected]> writes:
Scott> As one of the AC shepherds for the policy, I am hoping to
Scott> have a discussion, both here on PPML at at the upcoming ARIN
Scott> meeting, to cover a few key points:
Scott> - Is the problem statement clear to the community? Do you
Scott> have any questions on the problem the proposal is attempting
Scott> to solve?
Yes, I think so.
It's a variation of the problem that Canadian Canadian Third Party
Internet Access has that we dealt with, and is 4.2.3.8 now.
>> Currently, a number of mobile networks are using non-RIR-assigned
>> space internally to meet customer demand. However, there is
>> insufficient private space (RFC1918, etc.) available for internal
>> use, so other unassigned space is currently being used. As this
>> unassigned space is brought into service via reclamation,
So, as stated here 3GPP networks have blown through 65536+4096+256 /24s,
plus in many cases, an additional 65536 /24s from a squatted /8... how
will an additional /8 even help them?
My understanding is that many operators have avoided RFC1918 space
because that likely conflicts for many devices on their wifi interface,
so actually, they have only their squatted /8. How will a second /8
help them (assuming that there was one available).
I thought the answer was that IPv6 was required for 3GPP's "4G"/"LTE" step.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 93, Issue 13
*****************************************
