Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
Dear SIG members,
The proposal, 'Requiring aggregation for IPv6 subsequent allocations', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 28 in Beijing, China, 25-28 August 2009.
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, Jian and Ching-Heng
________________________________________________________________________
prop-076-v001: Requiring aggregation for IPv6 subsequent allocations ________________________________________________________________________
Authors: Tomohiro Fujisaki fujisaki@syce.net
Akira Nakagawa Toshio Tachibana Fuminori Tanizaki
Version: 1
Date: 29 July 2009
1. Introduction ----------------
This is a proposal to make it a condition that LIRs aggregate subsequent IPv6 allocations that they receive from APNIC.
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 the criteria for subsequent allocations.
For consistency, the routing requirement should be applied also in subsequent allocation criteria.
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 is currently discussing the following proposal to remove routing requirements from 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 requirement for aggregation for subsequent allocation criteria. Neither RIR is has any proposal to modify these criteria.
4. Details -----------
This is a proposal to add the requirement under the subsequent IPv6 allocation criteria to aggregate subsequent IPv6 allocations as a single prefix.
5. Pros/Cons -------------
5.1 Advantages:
- By describing clearly in the policy as a requirement, it may contribute to limiting routing expansion of the global IPv6 routing table in the future.
5.2 Disadvantages:
- This proposal may just be a nonbinding requirement.
- APNIC policy may be more strict than other regions if other RIR communities decided to remove aggregation requirement from their policy.
6. Effect on APNIC members ---------------------------
APNIC members will be required to aggregate subsequent allocations as a single prefix.
7. Effect on NIRs ------------------
Same as above.
8. References --------------
[1] See section 5.2.1, "IPv6 Address Allocation and Assignment Policy" http://www.apnic.net/ipv6-address-policy#5.2.1
Tomohiro, Akira, Toshio, and Fuminori,
I always read suggestions about _required_ aggregation with some scepticism.
As you may have seen the number of people dis-aggregating (fragmenting) v4 space for various reasons is becoming more popular. If that trend continues in v6, I'm at odds with the notion that advertising the aggregate of two or more contiguous prefixes actually helps the routing table when it is highly likely that the member will still announce the more specific prefixes for traffic engineering purposes.
And I think you highlight this in your disadvantages.. "This proposal may just be a nonbinding requirement."
Cheers Terry
On 29/07/2009, at 4:48 PM, Randy Bush wrote:
prop-076-v001: Requiring aggregation for IPv6 subsequent allocations ________________________________________________________________________
Authors: Tomohiro Fujisaki fujisaki@syce.net
Akira Nakagawa Toshio Tachibana Fuminori TanizakiVersion: 1
Date: 29 July 2009
- Introduction
This is a proposal to make it a condition that LIRs aggregate subsequent IPv6 allocations that they receive from APNIC.
- Summary of the current problem
The initial IPv6 address allocation criteria requires that LIRs:
"Plan to provide IPv6 connectivity to organizations to which itwill make assignments, by advertising that connectivity through its single aggregated address allocation."[1]
However, there is no similar aggregation requirement in the criteria for subsequent allocations.
For consistency, the routing requirement should be applied also in subsequent allocation criteria.
- Situation in other RIRs
LACNIC:
The LACNIC community is currently discussing the followingproposal 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 AllocationPolicy
http://www.lacnic.net/documentos/politicas/LAC-2007-01v3-propuesta-en.pdf
RIPE:
The RIPE community is currently discussing the following proposalto remove routing requirements from IPv6 policy:
2009-06: Removing Routing Requirements from the IPv6 Address Allocation Policy http://www.ripe.net/ripe/policies/proposals/2009-06.htmlAfriNIC and ARIN initial IPv6 allocation criteria require a plan to aggregate, with no requirement for aggregation for subsequent allocation criteria. Neither RIR is has any proposal to modify these criteria.
- Details
This is a proposal to add the requirement under the subsequent IPv6 allocation criteria to aggregate subsequent IPv6 allocations as a single prefix.
- Pros/Cons
5.1 Advantages:
- By describing clearly in the policy as a requirement, it may contribute to limiting routing expansion of the global IPv6 routing table in the future.5.2 Disadvantages:
- This proposal may just be a nonbinding requirement. - APNIC policy may be more strict than other regions if other RIR communities decided to remove aggregation requirement from their policy.
- Effect on APNIC members
APNIC members will be required to aggregate subsequent allocations as a single prefix.
- Effect on NIRs
Same as above.
- References
[1] See section 5.2.1, "IPv6 Address Allocation and Assignment Policy" http://www.apnic.net/ipv6-address-policy#5.2.1
sig-policy: APNIC SIG on resource managementpolicy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
there is a long history of rir policy not controlling routing
randy
Hi Tomohiro, Akira, Toshio, and Fuminori,
I'm quite interested by the proposal, but I'm actually wondering how to make aggregation a condition of receiving further IPv6 allocations?
Every AS has traffic engineering needs, and that can't be achieved with just a single announcement. :-(
Would it be worth augmenting the proposal by stating that "recipients of further IPv6 allocations should attempt to minimise the deaggregation of the allocation as much as is technically feasible".
Perhaps also put in a mention of the RIPE-399 document (shameless advert, but the authors hope that the RIRs would include mention of the document as part of any allocation) which encourages ISPs to aggregate their announcements as much as possible and gives some of the reasons why deaggregation is a problem.
Also, what would the penalty be if they don't aggregate? Withdraw the allocation?
philip --
Randy Bush said the following on 29/7/09 16:48 :
prop-076-v001: Requiring aggregation for IPv6 subsequent allocations ________________________________________________________________________
Authors: Tomohiro Fujisaki fujisaki@syce.net
Akira Nakagawa Toshio Tachibana Fuminori TanizakiVersion: 1
Date: 29 July 2009
- Introduction
This is a proposal to make it a condition that LIRs aggregate subsequent IPv6 allocations that they receive from APNIC.
- 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 the criteria for subsequent allocations.
For consistency, the routing requirement should be applied also in subsequent allocation criteria.
- 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 Policyhttp://www.lacnic.net/documentos/politicas/LAC-2007-01v3-propuesta-en.pdf
RIPE:
The RIPE community is currently discussing the following proposalto remove routing requirements from IPv6 policy:
2009-06: Removing Routing Requirements from the IPv6 Address Allocation Policy http://www.ripe.net/ripe/policies/proposals/2009-06.htmlAfriNIC and ARIN initial IPv6 allocation criteria require a plan to aggregate, with no requirement for aggregation for subsequent allocation criteria. Neither RIR is has any proposal to modify these criteria.
- Details
This is a proposal to add the requirement under the subsequent IPv6 allocation criteria to aggregate subsequent IPv6 allocations as a single prefix.
- Pros/Cons
5.1 Advantages:
- By describing clearly in the policy as a requirement, it may contribute to limiting routing expansion of the global IPv6 routing table in the future.5.2 Disadvantages:
- This proposal may just be a nonbinding requirement. - APNIC policy may be more strict than other regions if other RIR communities decided to remove aggregation requirement from their policy.
- Effect on APNIC members
APNIC members will be required to aggregate subsequent allocations as a single prefix.
- Effect on NIRs
Same as above.
- References
[1] See section 5.2.1, "IPv6 Address Allocation and Assignment Policy" http://www.apnic.net/ipv6-address-policy#5.2.1
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
I think if you wish to discourage deaggregation you need to make it easier to get extra allocations of ipv6.
I for example have a /32... and I have equipment in 3 states of Australia and am looking at some offshore facilities. I have had to break up my /32 into 8 * /35's. We do not have interstate (or international) capacity to join our networks, and indeed in the different locations we use different providers.
I also have multiple customers who are in the same position, who even have facilities in the same city, but in different datacentes - i.e. Globalswitch and Equinix, but do not have the budgets to pay for inter-datacentre capacity, and again may use different upstreams in each location.
I am not suggesting we hand everyone thousands of /32's, but we do have an awful lot of ipv6, and if someone can justify it, then they should be able to get extra allocations without too much drama.
Many people automatically just suggest that you build interstate/international capacity to aggregate, or to use tunnels and so on, but I think these are really impractical suggestions.
When my company installs some equipment in Auckland, and I want v4 and v6 to multiple providers... what are the current recommendations on how best to accomplish this within my own /32?
Traffic engineering requirements are one thing... sometimes basic connectivity is the first thing that needs to be addressed.
-- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there?
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy- bounces@lists.apnic.net] On Behalf Of Philip Smith Sent: Thursday, 6 August 2009 3:23 PM To: Policy SIG Subject: Re: [sig-policy] prop-076: Requiring aggregation for IPv6 subsequent allocations
Hi Tomohiro, Akira, Toshio, and Fuminori,
I'm quite interested by the proposal, but I'm actually wondering how to make aggregation a condition of receiving further IPv6 allocations?
Every AS has traffic engineering needs, and that can't be achieved with just a single announcement. :-(
Would it be worth augmenting the proposal by stating that "recipients of further IPv6 allocations should attempt to minimise the deaggregation of the allocation as much as is technically feasible".
Perhaps also put in a mention of the RIPE-399 document (shameless advert, but the authors hope that the RIRs would include mention of the document as part of any allocation) which encourages ISPs to aggregate their announcements as much as possible and gives some of the reasons why deaggregation is a problem.
Also, what would the penalty be if they don't aggregate? Withdraw the allocation?
philip
Randy Bush said the following on 29/7/09 16:48 :
_
prop-076-v001: Requiring aggregation for IPv6 subsequent allocations
_
Authors: Tomohiro Fujisaki fujisaki@syce.net
Akira Nakagawa Toshio Tachibana Fuminori TanizakiVersion: 1
Date: 29 July 2009
- Introduction
This is a proposal to make it a condition that LIRs aggregate
subsequent
IPv6 allocations that they receive from APNIC.
- Summary of the current problem
The initial IPv6 address allocation criteria requires that LIRs:
"Plan to provide IPv6 connectivity to organizations to which itwill
make assignments, by advertising that connectivity through its single aggregated address allocation."[1]However, there is no similar aggregation requirement in the criteria
for
subsequent allocations.
For consistency, the routing requirement should be applied also in subsequent allocation criteria.
- Situation in other RIRs
LACNIC:
The LACNIC community is currently discussing the followingproposal
to remove the requirement to announce an initial allocation as a single prefix in favour of announcing the prefix with theminimum
possible level of disaggregation: 2007-01: Modifications to the IPv6 Prefix Initial AllocationPolicy
http://www.lacnic.net/documentos/politicas/LAC-2007-01v3-propuesta-
en.pdf
RIPE:
The RIPE community is currently discussing the followingproposal
to remove routing requirements from IPv6 policy:
2009-06: Removing Routing Requirements from the IPv6 Address Allocation Policy http://www.ripe.net/ripe/policies/proposals/2009-06.htmlAfriNIC and ARIN initial IPv6 allocation criteria require a plan to aggregate, with no requirement for aggregation for subsequent
allocation
criteria. Neither RIR is has any proposal to modify these criteria.
- Details
This is a proposal to add the requirement under the subsequent IPv6 allocation criteria to aggregate subsequent IPv6 allocations as a
single
prefix.
- Pros/Cons
5.1 Advantages:
- By describing clearly in the policy as a requirement, it may contribute to limiting routing expansion of the global IPv6 routing table in the future.5.2 Disadvantages:
- This proposal may just be a nonbinding requirement. - APNIC policy may be more strict than other regions if other RIR communities decided to remove aggregation requirement from their policy.
- Effect on APNIC members
APNIC members will be required to aggregate subsequent allocations as
a
single prefix.
- Effect on NIRs
Same as above.
- References
[1] See section 5.2.1, "IPv6 Address Allocation and Assignment
Policy"
http://www.apnic.net/ipv6-address-policy#5.2.1
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
Hi Philip,
Thank you so much for your comments.
| I'm quite interested by the proposal, but I'm actually wondering how to | make aggregation a condition of receiving further IPv6 allocations? | | Every AS has traffic engineering needs, and that can't be achieved with | just a single announcement. :-(
Do you mean many ASes who request additional address block will have an intention to announce de-aggregated prefixes? I think a large initial allocation will be same in this sense.
As a viewpoint of traffic engineering, I heard the proposal to remove aggregation requirement from the initial allocation criteria in LACIC mentioned this point as one main reason.
And we had related discussion in last JPOPM. The discussion summary is, we understand there are many demands to announce de-aggregated address block for traffic engineering, but still we should state this point somewhere in the policy document, not in the supplement document like guidelines.
| Would it be worth augmenting the proposal by stating that "recipients of | further IPv6 allocations should attempt to minimise the deaggregation of | the allocation as much as is technically feasible".
Thank you so much for drafting the elegant sentence! Do you think this can be inserted as a 'subsequent allocation criteria' in the policy document? (Then, I think 'should' should be changed to 'have to', and it would be no big difference in this case.)
| Perhaps also put in a mention of the RIPE-399 document (shameless | advert, but the authors hope that the RIRs would include mention of the | document as part of any allocation) which encourages ISPs to aggregate | their announcements as much as possible and gives some of the reasons | why deaggregation is a problem.
Agreed.
| Also, what would the penalty be if they don't aggregate? Withdraw the | allocation?
Yep, this is a big problem. Currently, no penalty in the case of initial allocation, so, I personally think it should be same. However, if this criteria is stated clearly in the policy document, ASes that have problems to receive more address prefix can say no on the ground of this policy.
| philip | --
Yours Sincerely, -- Tomohiro Fujisaki
| | | Randy Bush said the following on 29/7/09 16:48 : | > | > ________________________________________________________________________ | > | > prop-076-v001: Requiring aggregation for IPv6 subsequent allocations | > ________________________________________________________________________ | > | > | > Authors: Tomohiro Fujisaki | > fujisaki@syce.net | > | > Akira Nakagawa | > Toshio Tachibana | > Fuminori Tanizaki | > | > Version: 1 | > | > Date: 29 July 2009 | > | > | > | > 1. Introduction | > ---------------- | > | > This is a proposal to make it a condition that LIRs aggregate subsequent | > IPv6 allocations that they receive from APNIC. | > | > | > 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 the criteria for | > subsequent allocations. | > | > For consistency, the routing requirement should be applied also in | > subsequent allocation criteria. | > | > | > 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 is currently discussing the following proposal | > to | > remove routing requirements from 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 requirement for aggregation for subsequent allocation | > criteria. Neither RIR is has any proposal to modify these criteria. | > | > 4. Details | > ----------- | > | > This is a proposal to add the requirement under the subsequent IPv6 | > allocation criteria to aggregate subsequent IPv6 allocations as a single | > prefix. | > | > | > 5. Pros/Cons | > ------------- | > | > 5.1 Advantages: | > | > - By describing clearly in the policy as a requirement, it may | > contribute to limiting routing expansion of the global IPv6 | > routing table in the future. | > | > | > 5.2 Disadvantages: | > | > - This proposal may just be a nonbinding requirement. | > | > - APNIC policy may be more strict than other regions if other | > RIR communities decided to remove aggregation requirement from | > their policy. | > | > | > 6. Effect on APNIC members | > --------------------------- | > | > APNIC members will be required to aggregate subsequent allocations as a | > single prefix. | > | > | > 7. Effect on NIRs | > ------------------ | > | > Same as above. | > | > | > 8. References | > -------------- | > | > [1] See section 5.2.1, "IPv6 Address Allocation and Assignment Policy" | > http://www.apnic.net/ipv6-address-policy#5.2.1 | > * 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 |
I agree very much with what Phil says here.
APNIC is a large region and there will be requirements for subsequent allocations in different geographic locations - which in many cases will not be able to be aggregated.
Example, my company may require IPv6 for NZ or Singapore or Japan... and we will source a local transit provider in those locations rather than building a global network for aggregation.
This policy, while its intent is a good one, does not meet the functional requirements of traffic engineering or allocations.
...Skeeve
-- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there?
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy- bounces@lists.apnic.net] On Behalf Of Philip Smith Sent: Thursday, 6 August 2009 3:23 PM To: Policy SIG Subject: Re: [sig-policy] prop-076: Requiring aggregation for IPv6 subsequent allocations
Hi Tomohiro, Akira, Toshio, and Fuminori,
I'm quite interested by the proposal, but I'm actually wondering how to make aggregation a condition of receiving further IPv6 allocations?
Every AS has traffic engineering needs, and that can't be achieved with just a single announcement. :-(
Would it be worth augmenting the proposal by stating that "recipients of further IPv6 allocations should attempt to minimise the deaggregation of the allocation as much as is technically feasible".
Perhaps also put in a mention of the RIPE-399 document (shameless advert, but the authors hope that the RIRs would include mention of the document as part of any allocation) which encourages ISPs to aggregate their announcements as much as possible and gives some of the reasons why deaggregation is a problem.
Also, what would the penalty be if they don't aggregate? Withdraw the allocation?
philip
Randy Bush said the following on 29/7/09 16:48 :
_
prop-076-v001: Requiring aggregation for IPv6 subsequent allocations
_
Authors: Tomohiro Fujisaki fujisaki@syce.net
Akira Nakagawa Toshio Tachibana Fuminori TanizakiVersion: 1
Date: 29 July 2009
- Introduction
This is a proposal to make it a condition that LIRs aggregate
subsequent
IPv6 allocations that they receive from APNIC.
- Summary of the current problem
The initial IPv6 address allocation criteria requires that LIRs:
"Plan to provide IPv6 connectivity to organizations to which itwill
make assignments, by advertising that connectivity through its single aggregated address allocation."[1]However, there is no similar aggregation requirement in the criteria
for
subsequent allocations.
For consistency, the routing requirement should be applied also in subsequent allocation criteria.
- Situation in other RIRs
LACNIC:
The LACNIC community is currently discussing the followingproposal
to remove the requirement to announce an initial allocation as a single prefix in favour of announcing the prefix with theminimum
possible level of disaggregation: 2007-01: Modifications to the IPv6 Prefix Initial AllocationPolicy
http://www.lacnic.net/documentos/politicas/LAC-2007-01v3-propuesta-
en.pdf
RIPE:
The RIPE community is currently discussing the followingproposal
to remove routing requirements from IPv6 policy:
2009-06: Removing Routing Requirements from the IPv6 Address Allocation Policy http://www.ripe.net/ripe/policies/proposals/2009-06.htmlAfriNIC and ARIN initial IPv6 allocation criteria require a plan to aggregate, with no requirement for aggregation for subsequent
allocation
criteria. Neither RIR is has any proposal to modify these criteria.
- Details
This is a proposal to add the requirement under the subsequent IPv6 allocation criteria to aggregate subsequent IPv6 allocations as a
single
prefix.
- Pros/Cons
5.1 Advantages:
- By describing clearly in the policy as a requirement, it may contribute to limiting routing expansion of the global IPv6 routing table in the future.5.2 Disadvantages:
- This proposal may just be a nonbinding requirement. - APNIC policy may be more strict than other regions if other RIR communities decided to remove aggregation requirement from their policy.
- Effect on APNIC members
APNIC members will be required to aggregate subsequent allocations as
a
single prefix.
- Effect on NIRs
Same as above.
- References
[1] See section 5.2.1, "IPv6 Address Allocation and Assignment
Policy"
http://www.apnic.net/ipv6-address-policy#5.2.1
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
Although I believe that encouraging principles of minimal route growth will be essential for the eventual success of IPv6, I nevertheless believe that the constraint suggested in this proposal of aggregating successive allocations would be impractical to implement or guarantee in all circumstances for either the xIR or the requestor, and I therefore regret that I cannot support this proposal on this basis.
Regards,
David Woodgate
At 04:48 PM 29/07/2009, Randy Bush wrote:
Dear SIG members,
The proposal, 'Requiring aggregation for IPv6 subsequent allocations', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 28 in Beijing, China, 25-28 August 2009.
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/proposalsRandy, Jian and Ching-Heng
prop-076-v001: Requiring aggregation for IPv6 subsequent allocations ________________________________________________________________________
Authors: Tomohiro Fujisaki fujisaki@syce.net
Akira Nakagawa Toshio Tachibana Fuminori TanizakiVersion: 1
Date: 29 July 2009
- Introduction
This is a proposal to make it a condition that LIRs aggregate subsequent IPv6 allocations that they receive from APNIC.
- 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 the criteria for subsequent allocations.
For consistency, the routing requirement should be applied also in subsequent allocation criteria.
- 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 Policyhttp://www.lacnic.net/documentos/politicas/LAC-2007-01v3-propuesta-en.pdf
RIPE:
The RIPE community is currently discussing the following proposalto remove routing requirements from IPv6 policy:
2009-06: Removing Routing Requirements from the IPv6 Address Allocation Policy http://www.ripe.net/ripe/policies/proposals/2009-06.htmlAfriNIC and ARIN initial IPv6 allocation criteria require a plan to aggregate, with no requirement for aggregation for subsequent allocation criteria. Neither RIR is has any proposal to modify these criteria.
- Details
This is a proposal to add the requirement under the subsequent IPv6 allocation criteria to aggregate subsequent IPv6 allocations as a single prefix.
- Pros/Cons
5.1 Advantages:
- By describing clearly in the policy as a requirement, it may contribute to limiting routing expansion of the global IPv6 routing table in the future.5.2 Disadvantages:
- This proposal may just be a nonbinding requirement. - APNIC policy may be more strict than other regions if other RIR communities decided to remove aggregation requirement from their policy.
- Effect on APNIC members
APNIC members will be required to aggregate subsequent allocations as a single prefix.
- Effect on NIRs
Same as above.
- References
[1] See section 5.2.1, "IPv6 Address Allocation and Assignment Policy" http://www.apnic.net/ipv6-address-policy#5.2.1
sig-policy: APNIC SIG on resource managementpolicy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Activity Summary
- 5145 days inactive
- 5145 days old
- sig-policy@lists.apnic.net
- 6 participants
- 7 comments