Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
[sig-policy] prop-082: Removing aggregation criteria for IPv6 initial allocations
Dear SIG members,
The proposal, 'Removing aggregation criteria for IPv6 initial allocations', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 29 in Kuala Lumpur, 1-5 March 2010.
We invite you to review and comment on the proposal on the mailing list before the meeting.
The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal:
- Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective?
Information about this and other policy proposals is available from:
http://www.apnic.net/policy/proposals
Randy, Ching-Heng, and Terence
________________________________________________________________________
prop-082-v001: Removing aggregation criteria for IPv6 initial allocations ________________________________________________________________________
Author: Tomohiro Fujisaki fujisaki@syce.net
Co-authors: Akira Nakagawa Fuminori Tanizaki Masaru Akai Toshio Tachibana
Version: 1
Date: 2 February 2010
1. Introduction ----------------
This is a proposal to remove the aggregation requirement from the IPv6 initial allocation policy.
2. Summary of the current problem ----------------------------------
The initial IPv6 address allocation criteria requires that LIRs:
"Plan to provide IPv6 connectivity to organizations to which it will make assignments, by advertising that connectivity through its single aggregated address allocation."[1]
However, there is no similar aggregation requirement in either the criteria for subsequent allocations, or in the new IPv6 allocation criteria for APNIC Members.
Including the aggregation requirement is problematic for two reasons:
1. It is inconsistent with the criteria for IPv6 allocations under two other APNIC policies, which do not require aggregation. These policies are:
- Subsequent IPv6 allocations - The new kickstart IPv6 allocation criteria to be implemented 10 February 2010 [2]
2. Registry policy should not concern itself strongly with routing issues.
3. Situation in other RIRs ---------------------------
LACNIC:
The LACNIC community is currently discussing the following proposal to remove the requirement to announce an initial allocation as a single prefix in favour of announcing the prefix with the minimum possible level of disaggregation:
2007-01: Modifications to the IPv6 Prefix Initial Allocation Policy <http://www.lacnic.net/documentos/politicas/ LAC-2007-01v3-propuesta-en.pdf>
RIPE:
The RIPE community has recently removed routing requirements from its IPv6 policy:
2009-06: Removing Routing Requirements from the IPv6 Address Allocation Policy http://www.ripe.net/ripe/policies/proposals/2009-06.html
AfriNIC and ARIN initial IPv6 allocation criteria require a plan to aggregate, with no aggregation requirement for subsequent allocation criteria. Neither RIR has any proposal to modify these criteria.
4. Details -----------
This is a proposal to:
4.1 Remove the requirement under the initial IPv6 allocation criteria to aggregate an initial IPv6 allocation as a single prefix.
4.2 Include a stronger recommendation about the importance of aggregation to the IPv6 policy document.
The APNIC IPv6 policy document currently does include information about the importance of aggregation[3]. However, it is the opinion of this proposal's authors that the recommendation should be more strongly expressed.
5. Pros/Cons -------------
5.1 Advantages
- This policy lowers the barriers for obtaining IPv6 address.
- Other RIR communities are discussing removing aggregation requirements from their policies, so it would be appropriate for APNIC policy to maintain similar criteria to other regions.
5.2 Disadvantages
- By removing the aggregation requirement in the policy, deaggregated routes may begin to be announced more frequently.
6. Effect on APNIC Members ---------------------------
None.
7. Effect on NIRs ------------------
None.
8. References --------------
[1] See section 5.2.1, "IPv6 Address Allocation and Assignment Policy" http://www.apnic.net/policy/ipv6-address-policy#5.2.1
[2] prop-073: Simplifying allocation/assignment of IPv6 to APNIC Members with existing IPv4 addresses http://www.apnic.net/policy/proposals/prop-073
[3] See section 3.4, "IPv6 Address Allocation and Assignment Policy" http://www.apnic.net/policy/ipv6-address-policy#3.4
On 02/02/2010, at 8:09 PM, Randy Bush wrote:
- Do you support or oppose this proposal?
not just yet, as it stands.
[..snip..]
1. It is inconsistent with the criteria for IPv6 allocations under two other APNIC policies, which do not require aggregation. These policies are: - Subsequent IPv6 allocations
can you highlight the exact section in the IPv6 policies where subsequent allocation do not require aggregation?
- The new kickstart IPv6 allocation criteria to be implemented 10 February 2010 [2]
I don't recall that aggregation was actually discussed either at the mic or on-list wrt prop-73.
Prop-73 called for simplification of application criteria. I don't believe the intent (at the time) was to remove the aggregation requirement. However that said see my response to prop-83.
2. Registry policy should not concern itself strongly with routing issues.
I'm mostly in agreement here. Registries are not the routing police. In which case cast your eyes over section 5.1 of the IPv4 policy.
- Details
This is a proposal to:
4.1 Remove the requirement under the initial IPv6 allocation criteria to aggregate an initial IPv6 allocation as a single prefix.
"announce an initial allocation as a single (aggregate) prefix" perhaps?
4.2 Include a stronger recommendation about the importance of aggregation to the IPv6 policy document.
The APNIC IPv6 policy document currently does include information about the importance of aggregation[3]. However, it is the opinion of this proposal's authors that the recommendation should be more strongly expressed.
therein I see organisations taking a black and white approach to 'strong recommendations'.
I dare say it may not affect the position on people's filtering practices.I think just leave it out.
- Pros/Cons
5.1 Advantages
- This policy lowers the barriers for obtaining IPv6 address.
Does it? I could perhaps live with the case that this policy allows IPv6 addresses be deployed in scenarios that may have a better fit to an organisations current practice.
- Other RIR communities are discussing removing aggregation requirements from their policies, so it would be appropriate for APNIC policy to maintain similar criteria to other regions.
I generally agree with removal of aggregation requirements, but not because the other RIRs are.
I think that removing aggregation requirements also aids in conservation in multi-site/multiple AS topologies. (He says glibly when thinking about the size of IPv6 ;)
5.2 Disadvantages
- By removing the aggregation requirement in the policy, deaggregated routes may begin to be announced more frequently.
Agree.
- Effect on NIRs
None.
really??
Terry
Hi Terry,
Thank you so much for your comments.
From: Terry Manderson terry@terrym.net Subject: Re: [sig-policy] prop-082: Removing aggregation criteria for IPv6 initial allocations Date: Thu, 4 Feb 2010 16:21:03 +1000
| > 1. It is inconsistent with the criteria for IPv6 allocations under | > two other APNIC policies, which do not require aggregation. These | > policies are: | > | > - Subsequent IPv6 allocations | | can you highlight the exact section in the IPv6 policies where subsequent allocation do not require aggregation?
Current IPv6 policy:
http://www.apnic.net/policy/ipv6-address-policy
describes the initial allocation criteria at section 5.1.1, and the subsequent allocation criteria is defined at 5.2.1. The subsequent allocation criteria is now an utilization requirement only.
| > - The new kickstart IPv6 allocation criteria to be | > implemented 10 February 2010 [2] | | I don't recall that aggregation was actually discussed either at the mic or on-list wrt prop-73. | | Prop-73 called for simplification of application criteria. I don't believe the intent (at the time) was to remove the aggregation requirement. However that said see my response to prop-83.
I agree prop-73 did not intent that, but the implementation will have no concern about the aggregation.
| > 2. Registry policy should not concern itself strongly with routing | > issues. | > | | I'm mostly in agreement here. Registries are not the routing police. In which case cast your eyes over section 5.1 of the IPv4 policy. | | > | > 4. Details | > ----------- | > | > This is a proposal to: | > | > 4.1 Remove the requirement under the initial IPv6 allocation criteria to | > aggregate an initial IPv6 allocation as a single prefix. | > | | "announce an initial allocation as a single (aggregate) prefix" perhaps?
Yes, thank you. This should be same as policy description.
| > 4.2 Include a stronger recommendation about the importance of | > aggregation to the IPv6 policy document. | > | > The APNIC IPv6 policy document currently does include information | > about the importance of aggregation[3]. However, it is the opinion | > of this proposal's authors that the recommendation should be more | > strongly expressed. | > | | therein I see organisations taking a black and white approach to 'strong recommendations'. | | I dare say it may not affect the position on people's filtering practices.I think just leave it out.
I think this is one discussion point.
Aggregation in IPv6 will be more important than IPv4 since IPv6 address has longer bit length, will have more routes than IPv4 (I hope so:-)), and some backbone routers will have to maintain both IPv4 and IPv6 routes. So I want to emphasize importance of aggregation to suppress de-aggrigation without any technical requirement in this document.
| > 5. Pros/Cons | > ------------- | > | > 5.1 Advantages | > | > - This policy lowers the barriers for obtaining IPv6 address. | > | | Does it? I could perhaps live with the case that this policy allows IPv6 addresses be deployed in scenarios that may have a better fit to an organisations current practice.
I'm sorry this may be over-description, but my intention here is that this policy will reduce number of requirements.
| > - Other RIR communities are discussing removing aggregation | > requirements from their policies, so it would be appropriate for | > APNIC policy to maintain similar criteria to other regions. | > | | I generally agree with removal of aggregation requirements, but not because the other RIRs are. | | I think that removing aggregation requirements also aids in conservation in multi-site/multiple AS topologies. (He says glibly when thinking about the size of IPv6 ;)
Yes, I also think that is one advantage, but I'm not sure it will work in the initial allocation size, almost all of them are /32 in the global internet context, in which many routers may filter longer prefix thant /32.
| > 5.2 Disadvantages | > | > - By removing the aggregation requirement in the policy, | > deaggregated routes may begin to be announced more frequently. | > | | Agree. | | | > | > 7. Effect on NIRs | > ------------------ | > | > None. | > | | really??
Should I add something like 'NIRs should implement same policy ...' or do you have other concern about NIRs?
Yours Sincerely, -- Tomohiro Fujisaki
Activity Summary
- 4689 days inactive
- 4689 days old
- sig-policy@lists.apnic.net
- 3 participants
- 2 comments