I am less concerned about aggregation in IPv6.
Since the majority of the aggregation in IPv4 is the result of multiple prefixes being assigned to a few large organizations over time for growth (something like 30% of the routing table is held by the top 10 organizations), I think we have a lot more headroom in IPv6 to support address portability.
Making it unnecessarily and hugely expensive for customers to change ISPs is detrimental to the customers and the market in general by reducing competition and lowering the quality of service. Such an action should only be taken if it is absolutely critical to the continued functioning of the network.
In IPv4, we had need to do so. We have relaxed the extent to which we do so substantially in IPv4 seeking the balance between the minimum extent to which it is necessary to preserve a functional internet. As router technology and scale continue to improve, larger routing tables will be more feasible. (Remember, when CIDR was started, a 65K prefix table was a mighty fearful thing. Today, 400K prefixes is considered normal and many vendors are claiming 1M can be supported in their core routers.)
The prefix:ASN average ratio today is roughly 10 in IPv4. I expect IPv6 will probably settle in around 1.6-2.5.
Assuming continued growth in ASNs along the (strangely linear) lines seen here:
I would expect about 65,000 ASNs in 5 years and 140,000 ASNs in 20 years.
That's roughly 350,000 IPv6 prefixes in 20 years.
Bottom line, if we can get rid of the massive IPv4 RIB/FIB mess in the next 5 years, we've got more than enough headroom to allow aggregation to be a concern of the past.
Owen
On Mar 12, 2012, at 12:21 AM, Terence Zhang YH wrote:
Hi David,
My concerns about prop-101 is not address consumption but route aggregation,
I am afraid the popular use of portable assignments will make route aggregation less possible.
"2000 addresses or 200 /64s" seems to serve the 'conservation' purpose, but not the 'aggregation' purpose,
I think we can explicitly define the situations where renumbering will
result in a significant impact, which cannot be aviod technically.
Regards
Terence
----- Original Message -----
Sent: Friday, March 09, 2012 10:16 AM
Subject: Re: [sig-policy] prop-101 Returned to mailing list and Newversionposted
Terence,
May I ask whether you consider that the ARIN criteria adequately meet your concerns? For example, if I cut and paste the ARIN criteria (especially the "2000 addresses or 200 /64s" criteria), would that be sufficient gain your support for the proposal?
Regards, David
At 12:32 PM 9/03/2012, Terence Zhang YH wrote:
What I mean is I support expanding the current portable assignment criterias (multihome, IXP, CI),
but not to replace the current criterias with a 'reasonable justification'.
Regards
Terence
- ----- Original Message -----
- From: Owen DeLong
- To: Terence Zhang YH
- Cc: Dean Pemberton ; Randy Whitney ; sig-policy@apnic.net
- Sent: Friday, March 09, 2012 12:24 AM
- Subject: Re: [sig-policy] prop-101 Returned to mailing list and Newversionposted
- I'm not sure I fully understand your concern here, Terrence. ARIN has been issuing portable /48 assignments for a few years now. I think it is a reasonable minimum end-user assignment for IPv6. Can you elaborate on what you mean by "a few exceptional"?
- Owen
- On Mar 8, 2012, at 5:26 AM, Terence Zhang YH wrote:
- I don't object to allow a few exceptional /48 portable assignments,
- and I don't insist on the '2-year-expiration',
- but I suggest either define the 'reasonable justification' criterias explicitly & clearly
- or put in some safeguarding limit.
- Regards
- Terence
- ----- Original Message -----
- From: Dean Pemberton
- To: Randy Whitney
- Cc: sig-policy@apnic.net
- Sent: Thursday, March 08, 2012 11:14 AM
- Subject: Re: [sig-policy] prop-101 Returned to mailing list and Newversionposted
- I too support this version of the proposal
- On Thursday, March 8, 2012, Randy Whitney < randy.whitney@verizon.com> wrote:
- > I support this version of the proposal, which removes the controversial
- > 4.E.e Sunset Clause from the text, while leaving the 4.E.d Reporting
- > requirement.
- >
- > Best Regards,
- > Randy.
- >
- > On 3/6/2012 8:20 PM, Masato Yamanishi wrote:
- >> Dear SIG members
- >>
- >> # I'm sending this notification on behalf of Andy Linton, Policy SIG chair
- >>
- >> Version 3 of prop-101 Removing multihoming requirement for IPv6 portable
- >> assignments, did not reach consensus at the APNIC 33 Policy SIG.
- >> Therefore, this proposal is being returned to the author
- >> and the Policy SIG mailing list for further discussion.
- >>
- >> The author has submitted a revised proposal, prop-101-v004, for further
- >> discussion on the Policy SIG mailing list.
- >>
- >>
- >> Proposal details
- >> ---------------------
- >>
- >> This is a proposal to change the "IPv6 address allocation and assignment
- >> policy" to allow portable (that is, provider independent or PI)
- >> assignments of IPv6 address blocks to be made by APNIC to any
- >> organization with due justification and payment of standard fees,
- >> removing the current requirement that the requestor is or plans to be
- >> multihomed.
- >>
- >>
- >> Proposal details including the full text of the proposal, history, and
- >> links to mailing list discussions are available at:
- >>
- >> http://www.apnic.net/policy/proposals/prop-101
- >>
- >> Regards
- >>
- >> Andy, Skeeve, and Masato
- >>
- >>
- >>
- >> ------------------------------------------------------------------------
- >>
- >> prop-101-v004: Removing multihoming requirement for IPv6 portable
- >> assignments
- >>
- >> ------------------------------------------------------------------------
- >>
- >>
- >> 1. Introduction
- >> ---------------
- >>
- >> This a proposal to change the "IPv6 address allocation and assignment
- >> policy" to allow portable (that is, provider independent or PI)
- >> assignments of IPv6 address blocks to be made by APNIC to any
- >> organization with due justification and payment of standard fees,
- >> removing the current requirement that the requestor is or plans to be
- >> multihomed.
- >>
- >> 2. Summary of the current problem
- >> ---------------------------------
- >>
- >> Current APNIC policy only permits portable assignments of IPv6
- >> addresses to be made to an organization "if it is currently multihomed
- >> or plans to be multihomed within three months." [1] This requirement may
- >> unnecessarily complicate the implementation of IPv6 in some networks
- >> that are large or complex and use static assignment of addresses. It is
- >> therefore proposed to remove this requirement.
- >>
- >> IPv6 models tend to assume widespread assignment of registered IPv6
- >> addresses to equipment throughout a network; so if provider assigned
- >> IPv6 addresses have been used in an organization's network, then any
- >> change of ISP would require a renumbering of the entire network. Such
- >> renumbering may be feasible if the network is small or dynamically
- >> assigned (for example, through use of prefix-delegation), but
- >> renumbering a large, statically-assigned network would be a significant
- >> operational challenge, and may not be practically possible.
- >>
- >> Although it is likely that many large networks would be multihomed,
- >> there will be technical or commercial reasons why some will not be;
- >> currently those networks cannot obtain portable IPv6 assignments from
- >> APNIC, and would need to use assignments from their ISPs, and accept the
- >> associated difficulties of future renumbering if they do so. This
- >> consideration and complexity could significantly delay IPv6 use by the
- >> affected organisations, which is not desirable.
- >>
- >> There is a risk that removing the multihoming requirement could cause
- >> a significant increase in demand for portable assignments, which in turn
- >> could cause the Internet routing tables to grow beyond manageable
- >> levels. It is not feasible to quickly generate any realistic model of
- >> likely demand increase which would arise from the proposed policy
- >> change, but it is argued that any such increase would only be of a scale
- >> to produce a manageable impact on global routing, for reasons including:
- >>
- >> - Organizations would only be likely to seek portable addressing if
- >> they believed it were essential for their operations, as provider
- >> assigned > non-member agreement, under the standard terms& conditions and
- >> paying the standard fees applicable for their respective category.
- >>
- >> B. An organization will be automatically eligible for a minimum IPv6
- >> portable assignment if they have previously justified an IPv4
- >> portable assignment from APNIC.
- >>
- >> C. Requests by organizations that have not previously received an
- >> IPv4 portable assignment will need to be accompanied by:
- >>
- >> (a) a reasonable technical justification indicating why IPv6
- >> addresses from an ISP or other LIR are unsuitable - examples of
- >> suitable technical justifications may include (but are not
- >> limited to):
- >>
- >> (i) Demonstration that the relevant network is statically
- >> addressed and of a size or complexity that would make IPv6
- >> renumbering operationally impractical within an acceptable
- >> business period, together with evidence that dynamic or
- >> multiple addressing options are either not available from
- >> the relevant ISP or are unsuitable for use by the
- >> organization;
- >>
- >> (ii) Demonstration that any future renumbering of the relevant
- >> network could potentially interfere with services of a
- >> critical medical or civic nature;
- >>
- >> (b) A detailed plan of intended usage of the proposed address block
- >> over at least the 12 months following allocation.
- >>
- >> D. The minimum IPv6 portable assignment to any organization is to be
- >> an address block of /48. A portable assignment of a larger block
- >> (that is, a block with a prefix mask less than /48) may be made:
- >>
- >> (a) If it is needed to ensure that the HD-ratio for the planned
- >> network assignments from the block remains below the applied
- >> HD-ratio threshold specified in Section 5.3.1 of the APNIC IPv6
- >> policy [6], or;
- >>
- >> (b) If addressing is required for 2 or more of the organization's
- >> sites operating distinct and unconnected networks.
- >>
- >> Any requests for address blocks larger than the minimum size will
- >> need to be accompanied by a detailed plan of the intended usage of
- >> the proposed assignment over at least the following 12 months.
- >>
- >> E. In order to minimise routing table impacts:
- >>
- >> (a) Only one IPv6 address block is to be given to an organization
- >> upon an initial request for a portable assignment; subnets of
- >> this block may be assigned by the organization to its different
- >> sites if needed;
- >>
- >> (b) It is recommended that the APNIC Secretariat applies sparse
- >> allocation methodologies so that any subsequent requests from an
- >> organization for additional portable addressing would be
- >> accommodated where possible through a change of prefix mask of a
- >> previous assignment (for example, 2001:db8:1000::/48 -> ]
- >> 2001:db8:1000::/44), rather than through allocation of a new
- >> prefix. An additional prefix should only be allocated where it
- >> is not possible to simply change the prefix mask.
- >>
- >> (c) Any subsequent request for an additional portable assignment to
- >> an organization must be accompanied by information
- >> demonstrating:
- >>
- >> (i) Why an additional portable assignment is required, and why
- >>
- --
- Regards,
- Dean
- * sig-policy: APNIC SIG on resource management policy *
- _______________________________________________
- sig-policy mailing list
- sig-policy@lists.apnic.net
- http://mailman.apnic.net/mailman/listinfo/sig-policy
- * sig-policy: APNIC SIG on resource management policy *
- _______________________________________________
- sig-policy mailing list
- sig-policy@lists.apnic.net
- http://mailman.apnic.net/mailman/listinfo/sig-policy
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy