Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
Dear SIG members
A new version of the proposal “prop-111: Request-based expansion of IPv6 default allocation size has been sent to the Policy SIG for review.
There are changes to section 4. Proposed policy solution only.
Information about earlier versions is available from:
http://www.apnic.net/policy/proposals/prop-111
You are encouraged to express your views on the proposal:
- Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What change could be made to this proposal to make it more effective?
Please find the text of the proposal below.
Kind Regards,
Andy and Masato
---------------------------------------------------------------------- prop-111-v004 Request-based expansion of IPv6 default allocation size ----------------------------------------------------------------------
Author: Tomohiro Fujisaki fujisaki@syce.net
1. Problem statement --------------------
IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6 address allocation and assignment policy"[1]. It's better to expand this minimum allocation size up to /29 (/32 - /29) since:
- Before sparse allocation mechanism implemented in late 2006, /29 was reserved for all /32 allocations by sequential allocation method made from those old /23 blocks. These reserved blocks might be kept unused in the future.
- Sparse allocation mechanism was implemented in late 2006 with a /12 allocation from the IANA. Under the sparse allocation mechanism, there is no reservation size defined, and the space between allocations continues to change, depending on the remaining free pool available in APNIC.
However, the "APNIC guidelines for IPv6 allocation and assignment requests"[2] stated:
"In accordance with APNIC's "IPv6 address allocation and assignment policy", where possible, subsequent delegations to the same resource holder are made from an adjacent address block by growing the delegation into the free space remaining, unless disaggregated ranges are requested for multiple discrete networks."
So, it is expected that allocation up to /29 is guaranteed for consistency with allocations above. Based on the current situation, contiguous allocation of /29 can still be accommodated even under the sparse allocation mechanism (Current /32 allocations from the /12 block can grow up to /24 at this stage).
- After amended HD Ratio (0.94) and base calculation size (/56) was introduced (prop-031 and prop-033), to obtain address blocks larger than /32 and to request additional address blocks became harder especially for small and middle size ISPs.
- For traffic control purpose, some LIRs announce address blocks longer than /32 (e.g. /35). However, some ISPs may set filters to block address size longer than /32 since some filtering guidelines recommend to filter longer prefix than /32([3][4]). If LIRs have multiple /32, they can announce these blocks and its reachability will be better than longer prefix.
- If an LIR needs address blocks larger than /32, LIRs may tend to announce as a single prefix if a /29 is allocated initially at once. i.e., total number of announced prefixes in case 1 may be smaller than in case 2.
case 1: The LIR obtains /29 at the beginning of IPv6 network construction.
case 2: The LIR obtains /32, and /31, /30 additionally with the subsequent allocation mechanism.
2. Objective of policy change -----------------------------
This proposal modifies the eligibility for an organization to receive or extend an IPv6 address space up to a /29 (/32 -/29) by explaining how the extended space up to /29 will be used.
3. Situation in other regions -----------------------------
RIPE-NCC: The policy "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get up to /29 by default.
4. Proposed policy solution ----------------------------
- Change the text to "5.2.2 Minimum initial allocation size" of current policy document as below:
Organizations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. The organizations can receive up to /29 by providing utilization information of the whole address space.
- Change /32 to /29 in "5.2.3 Larger initial allocations”
Initial allocations larger than /29 may be justified if:
- Add following text as 5.3.4
5.3.4 Extend existing allocations to /29 LIRs that hold one or more IPv6 allocations are able to request extension of each of these allocations up to a /29 without meeting the utilization rate for subsequent allocation by providing their network plan to show how the whole address space will be used.
5. Explain the advantages of the proposal -----------------------------------------
- It is possible to utilize address blocks which is potentially unused into the future.
- Organizations can design their IPv6 networks more flexibly.
- It will be possible for LIRs to control traffic easier.
6. Explain the disadvantages of the proposal --------------------------------------------
Some people may argue this will lead to inefficient utilization of IPv6 space since LIRs can obtain huge address size unnecessarily. However, this will not happen because larger address size needs higher cost to maintain that address block.
7. Impact on resource holders -----------------------------
NIRs must implement this policy if it is implemented by APNIC.
8. References (if required) ---------------------------
[1] IPv6 address allocation and assignment policy http://www.apnic.net/policy/ipv6-address-policy
[2] APNIC guidelines for IPv6 allocation and assignment requests https://www.apnic.net/publications/media-library/documents/resource-guidelin...
[3] Packet Filter and Route Filter Recommendation for IPv6 at xSP routers https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendat...
[4] IPv6 BGP filter recommendations http://www.space.net/~gert/RIPE/ipv6-filters.html
Hi policy-sig ML colleagues,
I've modified section 4 '4. Proposed policy solution' in prop-111-v003. The purpose of this modification is only to adjust proposed policy text to current policy text. There are no changes in the context of the proposal.
Yours Sincerely, -- Tomohiro Fujisaki
From: Masato Yamanishi myamanis@japan-telecom.com Subject: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size Date: Wed, 17 Sep 2014 10:26:18 +1000
| Dear SIG members | | A new version of the proposal “prop-111: Request-based expansion of IPv6 | default allocation size has been sent to the Policy SIG for review. | | There are changes to section 4. Proposed policy solution only. | | Information about earlier versions is available from: | | http://www.apnic.net/policy/proposals/prop-111 | | You are encouraged to express your views on the proposal: | | - Do you support or oppose the proposal? | - Is there anything in the proposal that is not clear? | - What change could be made to this proposal to make it more effective? | | Please find the text of the proposal below. | | Kind Regards, | | Andy and Masato | | | | ---------------------------------------------------------------------- | prop-111-v004 Request-based expansion of IPv6 default allocation size | ---------------------------------------------------------------------- | | Author: Tomohiro Fujisaki | fujisaki@syce.net | | | 1. Problem statement | -------------------- | | IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6 | address allocation and assignment policy"[1]. It's better to | expand this minimum allocation size up to /29 (/32 - /29) since: | | - Before sparse allocation mechanism implemented in late 2006, /29 | was reserved for all /32 allocations by sequential allocation | method made from those old /23 blocks. These reserved blocks | might be kept unused in the future. | | - Sparse allocation mechanism was implemented in late 2006 with a | /12 allocation from the IANA. Under the sparse allocation | mechanism, there is no reservation size defined, and the space | between allocations continues to change, depending on the | remaining free pool available in APNIC. | | However, the "APNIC guidelines for IPv6 allocation and | assignment requests"[2] stated: | | "In accordance with APNIC's "IPv6 address allocation and | assignment policy", where possible, subsequent delegations to the | same resource holder are made from an adjacent address block by | growing the delegation into the free space remaining, unless | disaggregated ranges are requested for multiple discrete | networks." | | So, it is expected that allocation up to /29 is guaranteed for | consistency with allocations above. Based on the current | situation, contiguous allocation of /29 can still be accommodated | even under the sparse allocation mechanism (Current /32 | allocations from the /12 block can grow up to /24 at this stage). | | - After amended HD Ratio (0.94) and base calculation size (/56) was | introduced (prop-031 and prop-033), to obtain address blocks larger | than /32 and to request additional address blocks became harder | especially for small and middle size ISPs. | | - For traffic control purpose, some LIRs announce address blocks | longer than /32 (e.g. /35). However, some ISPs may set filters to | block address size longer than /32 since some filtering | guidelines recommend to filter longer prefix than /32([3][4]). If | LIRs have multiple /32, they can announce these blocks and its | reachability will be better than longer prefix. | | - If an LIR needs address blocks larger than /32, LIRs may tend to | announce as a single prefix if a /29 is allocated initially at | once. i.e., total number of announced prefixes in case 1 may be | smaller than in case 2. | | case 1: | The LIR obtains /29 at the beginning of IPv6 network construction. | | case 2: | The LIR obtains /32, and /31, /30 additionally with the subsequent | allocation mechanism. | | 2. Objective of policy change | ----------------------------- | | This proposal modifies the eligibility for an organization to | receive or extend an IPv6 address space up to a /29 (/32 -/29) by | explaining how the extended space up to /29 will be used. | | | 3. Situation in other regions | ----------------------------- | | RIPE-NCC: | The policy "Extension of IPv6 /32 to /29 on a per-allocation vs | per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get | up to /29 by default. | | | 4. Proposed policy solution | ---------------------------- | | - Change the text to "5.2.2 Minimum initial allocation size" of | current policy document as below: | | Organizations that meet the initial allocation criteria are | eligible to receive an initial allocation of /32. The organizations | can receive up to /29 by providing utilization information of the whole | address space. | | - Change /32 to /29 in "5.2.3 Larger initial allocations” | | Initial allocations larger than /29 may be justified if: | | - Add following text as 5.3.4 | | 5.3.4 Extend existing allocations to /29 | LIRs that hold one or more IPv6 allocations are able to request | extension of each of these allocations up to a /29 without meeting | the utilization rate for subsequent allocation by providing their network | plan to show how the whole address space will be used. | | | 5. Explain the advantages of the proposal | ----------------------------------------- | | - It is possible to utilize address blocks which is potentially | unused into the future. | | - Organizations can design their IPv6 networks more flexibly. | | - It will be possible for LIRs to control traffic easier. | | | 6. Explain the disadvantages of the proposal | -------------------------------------------- | | Some people may argue this will lead to inefficient utilization of | IPv6 space since LIRs can obtain huge address size unnecessarily. | However, this will not happen because larger address size needs | higher cost to maintain that address block. | | | 7. Impact on resource holders | ----------------------------- | | NIRs must implement this policy if it is implemented by APNIC. | | | 8. References (if required) | --------------------------- | | [1] IPv6 address allocation and assignment policy | http://www.apnic.net/policy/ipv6-address-policy | | [2] APNIC guidelines for IPv6 allocation and assignment requests | https://www.apnic.net/publications/media-library/documents/resource-guidelin... | | [3] Packet Filter and Route Filter Recommendation for IPv6 at xSP routers | https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendat... | | [4] IPv6 BGP filter recommendations | http://www.space.net/~gert/RIPE/ipv6-filters.html
I remain opposed so long as we limit this to /29 for everyone.
I accept the idea of issuing (up to) the reserved /29s from the non-sparse allocations. However, I do not support:
1. unrestricted issuance of /29s to every organization regardless of needs. 2. Use of /29s where /28s can be issued.
I am familiar with Dean’s arguments, and he and I have agreed to disagree in the past many times.
Owen
On Sep 16, 2014, at 5:26 PM, Masato Yamanishi myamanis@japan-telecom.com wrote:
Dear SIG members
A new version of the proposal “prop-111: Request-based expansion of IPv6 default allocation size has been sent to the Policy SIG for review.
There are changes to section 4. Proposed policy solution only.
Information about earlier versions is available from:
http://www.apnic.net/policy/proposals/prop-111You are encouraged to express your views on the proposal:
- Do you support or oppose the proposal?
- Is there anything in the proposal that is not clear?
- What change could be made to this proposal to make it more effective?
Please find the text of the proposal below.
Kind Regards,
Andy and Masato
prop-111-v004 Request-based expansion of IPv6 default allocation size
Author: Tomohiro Fujisaki fujisaki@syce.net
- Problem statement
IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6 address allocation and assignment policy"[1]. It's better to expand this minimum allocation size up to /29 (/32 - /29) since:
- Before sparse allocation mechanism implemented in late 2006, /29
was reserved for all /32 allocations by sequential allocation method made from those old /23 blocks. These reserved blocks might be kept unused in the future.
- Sparse allocation mechanism was implemented in late 2006 with a
/12 allocation from the IANA. Under the sparse allocation mechanism, there is no reservation size defined, and the space between allocations continues to change, depending on the remaining free pool available in APNIC.
However, the "APNIC guidelines for IPv6 allocation and assignment requests"[2] stated:
"In accordance with APNIC's "IPv6 address allocation and assignment policy", where possible, subsequent delegations to the same resource holder are made from an adjacent address block by growing the delegation into the free space remaining, unless disaggregated ranges are requested for multiple discrete networks."
So, it is expected that allocation up to /29 is guaranteed for consistency with allocations above. Based on the current situation, contiguous allocation of /29 can still be accommodated even under the sparse allocation mechanism (Current /32 allocations from the /12 block can grow up to /24 at this stage).
- After amended HD Ratio (0.94) and base calculation size (/56) was
introduced (prop-031 and prop-033), to obtain address blocks larger than /32 and to request additional address blocks became harder especially for small and middle size ISPs.
- For traffic control purpose, some LIRs announce address blocks
longer than /32 (e.g. /35). However, some ISPs may set filters to block address size longer than /32 since some filtering guidelines recommend to filter longer prefix than /32([3][4]). If LIRs have multiple /32, they can announce these blocks and its reachability will be better than longer prefix.
- If an LIR needs address blocks larger than /32, LIRs may tend to
announce as a single prefix if a /29 is allocated initially at once. i.e., total number of announced prefixes in case 1 may be smaller than in case 2.
case 1: The LIR obtains /29 at the beginning of IPv6 network construction.
case 2: The LIR obtains /32, and /31, /30 additionally with the subsequent allocation mechanism.
- Objective of policy change
This proposal modifies the eligibility for an organization to receive or extend an IPv6 address space up to a /29 (/32 -/29) by explaining how the extended space up to /29 will be used.
- Situation in other regions
RIPE-NCC: The policy "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get up to /29 by default.
- Proposed policy solution
- Change the text to "5.2.2 Minimum initial allocation size" of
current policy document as below:
Organizations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. The organizations can receive up to /29 by providing utilization information of the whole address space.
- Change /32 to /29 in "5.2.3 Larger initial allocations”
Initial allocations larger than /29 may be justified if:
- Add following text as 5.3.4
5.3.4 Extend existing allocations to /29 LIRs that hold one or more IPv6 allocations are able to request extension of each of these allocations up to a /29 without meeting the utilization rate for subsequent allocation by providing their network plan to show how the whole address space will be used.
- Explain the advantages of the proposal
It is possible to utilize address blocks which is potentially unused into the future.
Organizations can design their IPv6 networks more flexibly.
It will be possible for LIRs to control traffic easier.
- Explain the disadvantages of the proposal
Some people may argue this will lead to inefficient utilization of IPv6 space since LIRs can obtain huge address size unnecessarily. However, this will not happen because larger address size needs higher cost to maintain that address block.
- Impact on resource holders
NIRs must implement this policy if it is implemented by APNIC.
- References (if required)
[1] IPv6 address allocation and assignment policy http://www.apnic.net/policy/ipv6-address-policy
[2] APNIC guidelines for IPv6 allocation and assignment requests https://www.apnic.net/publications/media-library/documents/resource-guidelin...
[3] Packet Filter and Route Filter Recommendation for IPv6 at xSP routers https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendat...
[4] IPv6 BGP filter recommendations http://www.space.net/~gert/RIPE/ipv6-filters.html
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,
Thank you so much for your comments.
Here, just I would like to confirm,
| 1. unrestricted issuance of /29s to every organization regardless of needs.
I've added some texts that LIRs would like to to obtain a additional block larger than /32 need to demonstrate their needs in version 3 (prop-111-v003).
From the mail I sent on 1st August:
| | I submitted revised version of: | “prop-111: Request-based expansion of IPv6 default allocation size" | | At the last policy sig discussion, I got concern about address allocation | without any constraint, and some criteria should be added to expand the | block size. | | In this revised proposal, I added the requirement to demonstrate need | for both initial and subsequent allocations to reflect such opinions. | | For initial allocation: | > The organizations | > can receive up to /29 by providing utilization information of the whole | > address space. | | For subsequent allocation: | > LIRs that hold one or more IPv6 allocations are able to request | > extension of each of these allocations up to a /29 without meeting | > the utilization rate for subsequent allocation by explaining | > how the whole address space will be used.
# The wording is slightly different from latest (v004) version.
Do you think corrent text is not enough?
Yours Sincerely, -- Tomohiro Fujisaki
Hi,
you have my support.
This proposal has been already made and approved/implemented (May2012) in the RIPE Region and as far as I can see, it was a good proposal and it has not caused any problems.
The /29s are reserved anyway, why not allow the LIRs to use them if they need a larger/additional block? From my experience, some LIRs may need more than just the /32 used for their main/primary network in order to test in a separate network a transitioning protocol or equipment. For this reason only I think that keeping the /29 reserved and not allocated is a waste.
Offcourse, the /29 allocation should be made upon request of the LIR. If the LIR needs it, he can just request it but not have to send any kind of justification (other than - I need/want the extension of the allocation from /32 to /29)
my 2 cents, elvis
On 17/09/14 10:26, Masato Yamanishi wrote:
Dear SIG members
A new version of the proposal "prop-111: Request-based expansion of IPv6 default allocation size has been sent to the Policy SIG for review.
There are changes to section 4. Proposed policy solution only.
Information about earlier versions is available from:
http://www.apnic.net/policy/proposals/prop-111
You are encouraged to express your views on the proposal:
- Do you support or oppose the proposal?
- Is there anything in the proposal that is not clear?
- What change could be made to this proposal to make it more effective?
Please find the text of the proposal below.
Kind Regards,
Andy and Masato
prop-111-v004 Request-based expansion of IPv6 default allocation size
Author: Tomohiro Fujisaki fujisaki@syce.net mailto:fujisaki@syce.net
- Problem statement
IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6 address allocation and assignment policy"[1]. It's better to expand this minimum allocation size up to /29 (/32 - /29) since:
- Before sparse allocation mechanism implemented in late 2006, /29
was reserved for all /32 allocations by sequential allocation method made from those old /23 blocks. These reserved blocks might be kept unused in the future.
- Sparse allocation mechanism was implemented in late 2006 with a
/12 allocation from the IANA. Under the sparse allocation mechanism, there is no reservation size defined, and the space between allocations continues to change, depending on the remaining free pool available in APNIC.
However, the "APNIC guidelines for IPv6 allocation and assignment requests"[2] stated:
"In accordance with APNIC's "IPv6 address allocation and assignment policy", where possible, subsequent delegations to the same resource holder are made from an adjacent address block by growing the delegation into the free space remaining, unless disaggregated ranges are requested for multiple discrete networks."
So, it is expected that allocation up to /29 is guaranteed for consistency with allocations above. Based on the current situation, contiguous allocation of /29 can still be accommodated even under the sparse allocation mechanism (Current /32 allocations from the /12 block can grow up to /24 at this stage).
- After amended HD Ratio (0.94) and base calculation size (/56) was
introduced (prop-031 and prop-033), to obtain address blocks larger than /32 and to request additional address blocks became harder especially for small and middle size ISPs.
- For traffic control purpose, some LIRs announce address blocks
longer than /32 (e.g. /35). However, some ISPs may set filters to block address size longer than /32 since some filtering guidelines recommend to filter longer prefix than /32([3][4]). If LIRs have multiple /32, they can announce these blocks and its reachability will be better than longer prefix.
- If an LIR needs address blocks larger than /32, LIRs may tend to
announce as a single prefix if a /29 is allocated initially at once. i.e., total number of announced prefixes in case 1 may be smaller than in case 2.
case 1: The LIR obtains /29 at the beginning of IPv6 network construction.
case 2: The LIR obtains /32, and /31, /30 additionally with the subsequent allocation mechanism.
- Objective of policy change
This proposal modifies the eligibility for an organization to receive or extend an IPv6 address space up to a /29 (/32 -/29) by explaining how the extended space up to /29 will be used.
- Situation in other regions
RIPE-NCC: The policy "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get up to /29 by default.
- Proposed policy solution
- Change the text to "5.2.2 Minimum initial allocation size" of
current policy document as below:
Organizations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. The organizations can receive up to /29 by providing utilization information of the whole address space.
- Change /32 to /29 in "5.2.3 Larger initial allocations"
Initial allocations larger than /29 may be justified if:
- Add following text as 5.3.4
5.3.4 Extend existing allocations to /29 LIRs that hold one or more IPv6 allocations are able to request extension of each of these allocations up to a /29 without meeting the utilization rate for subsequent allocation by providing their network plan to show how the whole address space will be used.
- Explain the advantages of the proposal
- It is possible to utilize address blocks which is potentially
unused into the future.
Organizations can design their IPv6 networks more flexibly.
It will be possible for LIRs to control traffic easier.
- Explain the disadvantages of the proposal
Some people may argue this will lead to inefficient utilization of IPv6 space since LIRs can obtain huge address size unnecessarily. However, this will not happen because larger address size needs higher cost to maintain that address block.
- Impact on resource holders
NIRs must implement this policy if it is implemented by APNIC.
- References (if required)
[1] IPv6 address allocation and assignment policy http://www.apnic.net/policy/ipv6-address-policy
[2] APNIC guidelines for IPv6 allocation and assignment requests https://www.apnic.net/publications/media-library/documents/resource-guidelin...
[3] Packet Filter and Route Filter Recommendation for IPv6 at xSP routers https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendat...
[4] IPv6 BGP filter recommendations http://www.space.net/~gert/RIPE/ipv6-filters.html http://www.space.net/%7Egert/RIPE/ipv6-filters.html
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
Support
On Sep 16, 2014, at 21:45, "Elvis Velea" <elvis@velea.eumailto:elvis@velea.eu> wrote:
Hi,
you have my support.
This proposal has been already made and approved/implemented (May2012) in the RIPE Region and as far as I can see, it was a good proposal and it has not caused any problems.
The /29s are reserved anyway, why not allow the LIRs to use them if they need a larger/additional block? From my experience, some LIRs may need more than just the /32 used for their main/primary network in order to test in a separate network a transitioning protocol or equipment. For this reason only I think that keeping the /29 reserved and not allocated is a waste.
Offcourse, the /29 allocation should be made upon request of the LIR. If the LIR needs it, he can just request it but not have to send any kind of justification (other than - I need/want the extension of the allocation from /32 to /29)
my 2 cents, elvis
On 17/09/14 10:26, Masato Yamanishi wrote: Dear SIG members
A new version of the proposal “prop-111: Request-based expansion of IPv6 default allocation size has been sent to the Policy SIG for review.
There are changes to section 4. Proposed policy solution only.
Information about earlier versions is available from:
http://www.apnic.net/policy/proposals/prop-111
You are encouraged to express your views on the proposal:
- Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What change could be made to this proposal to make it more effective?
Please find the text of the proposal below.
Kind Regards,
Andy and Masato
---------------------------------------------------------------------- prop-111-v004 Request-based expansion of IPv6 default allocation size ----------------------------------------------------------------------
Author: Tomohiro Fujisaki fujisaki@syce.netmailto:fujisaki@syce.net
1. Problem statement --------------------
IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6 address allocation and assignment policy"[1]. It's better to expand this minimum allocation size up to /29 (/32 - /29) since:
- Before sparse allocation mechanism implemented in late 2006, /29 was reserved for all /32 allocations by sequential allocation method made from those old /23 blocks. These reserved blocks might be kept unused in the future.
- Sparse allocation mechanism was implemented in late 2006 with a /12 allocation from the IANA. Under the sparse allocation mechanism, there is no reservation size defined, and the space between allocations continues to change, depending on the remaining free pool available in APNIC.
However, the "APNIC guidelines for IPv6 allocation and assignment requests"[2] stated:
"In accordance with APNIC's "IPv6 address allocation and assignment policy", where possible, subsequent delegations to the same resource holder are made from an adjacent address block by growing the delegation into the free space remaining, unless disaggregated ranges are requested for multiple discrete networks."
So, it is expected that allocation up to /29 is guaranteed for consistency with allocations above. Based on the current situation, contiguous allocation of /29 can still be accommodated even under the sparse allocation mechanism (Current /32 allocations from the /12 block can grow up to /24 at this stage).
- After amended HD Ratio (0.94) and base calculation size (/56) was introduced (prop-031 and prop-033), to obtain address blocks larger than /32 and to request additional address blocks became harder especially for small and middle size ISPs.
- For traffic control purpose, some LIRs announce address blocks longer than /32 (e.g. /35). However, some ISPs may set filters to block address size longer than /32 since some filtering guidelines recommend to filter longer prefix than /32([3][4]). If LIRs have multiple /32, they can announce these blocks and its reachability will be better than longer prefix.
- If an LIR needs address blocks larger than /32, LIRs may tend to announce as a single prefix if a /29 is allocated initially at once. i.e., total number of announced prefixes in case 1 may be smaller than in case 2.
case 1: The LIR obtains /29 at the beginning of IPv6 network construction.
case 2: The LIR obtains /32, and /31, /30 additionally with the subsequent allocation mechanism.
2. Objective of policy change -----------------------------
This proposal modifies the eligibility for an organization to receive or extend an IPv6 address space up to a /29 (/32 -/29) by explaining how the extended space up to /29 will be used.
3. Situation in other regions -----------------------------
RIPE-NCC: The policy "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get up to /29 by default.
4. Proposed policy solution ----------------------------
- Change the text to "5.2.2 Minimum initial allocation size" of current policy document as below:
Organizations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. The organizations can receive up to /29 by providing utilization information of the whole address space.
- Change /32 to /29 in "5.2.3 Larger initial allocations”
Initial allocations larger than /29 may be justified if:
- Add following text as 5.3.4
5.3.4 Extend existing allocations to /29 LIRs that hold one or more IPv6 allocations are able to request extension of each of these allocations up to a /29 without meeting the utilization rate for subsequent allocation by providing their network plan to show how the whole address space will be used.
5. Explain the advantages of the proposal -----------------------------------------
- It is possible to utilize address blocks which is potentially unused into the future.
- Organizations can design their IPv6 networks more flexibly.
- It will be possible for LIRs to control traffic easier.
6. Explain the disadvantages of the proposal --------------------------------------------
Some people may argue this will lead to inefficient utilization of IPv6 space since LIRs can obtain huge address size unnecessarily. However, this will not happen because larger address size needs higher cost to maintain that address block.
7. Impact on resource holders -----------------------------
NIRs must implement this policy if it is implemented by APNIC.
8. References (if required) ---------------------------
[1] IPv6 address allocation and assignment policy http://www.apnic.net/policy/ipv6-address-policy
[2] APNIC guidelines for IPv6 allocation and assignment requests https://www.apnic.net/publications/media-library/documents/resource-guidelin...
[3] Packet Filter and Route Filter Recommendation for IPv6 at xSP routers https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendat...
[4] IPv6 BGP filter recommendations http://www.space.net/~gert/RIPE/ipv6-filters.htmlhttp://www.space.net/%7Egert/RIPE/ipv6-filters.html
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.netmailto: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.netmailto:sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Hi Elvis,
Thnak you for your comments!
| This proposal has been already made and approved/implemented (May2012) | in the RIPE Region and as far as I can see, it was a good proposal and | it has not caused any problems. | | The /29s are reserved anyway, why not allow the LIRs to use them if | they need a larger/additional block? | From my experience, some LIRs may need more than just the /32 used for | their main/primary network in order to test in a separate network a | transitioning protocol or equipment. For this reason only I think that | keeping the /29 reserved and not allocated is a waste.
I'll introduce situation of ripe region in my presentation.
Yours Sincerely, -- Tomohiro Fujisaki
From: Elvis Velea elvis@velea.eu Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size Date: Wed, 17 Sep 2014 11:44:42 +1000
| Hi, | | you have my support. | | This proposal has been already made and approved/implemented (May2012) | in the RIPE Region and as far as I can see, it was a good proposal and | it has not caused any problems. | | The /29s are reserved anyway, why not allow the LIRs to use them if | they need a larger/additional block? | From my experience, some LIRs may need more than just the /32 used for | their main/primary network in order to test in a separate network a | transitioning protocol or equipment. For this reason only I think that | keeping the /29 reserved and not allocated is a waste. | | Offcourse, the /29 allocation should be made upon request of the | LIR. If the LIR needs it, he can just request it but not have to send | any kind of justification (other than - I need/want the extension of | the allocation from /32 to /29) | | my 2 cents, | elvis | | On 17/09/14 10:26, Masato Yamanishi wrote: | > Dear SIG members | > | > A new version of the proposal "prop-111: Request-based expansion of | > IPv6 | > default allocation size has been sent to the Policy SIG for review. | > | > There are changes to section 4. Proposed policy solution only. | > | > Information about earlier versions is available from: | > | > http://www.apnic.net/policy/proposals/prop-111 | > | > You are encouraged to express your views on the proposal: | > | > - Do you support or oppose the proposal? | > - Is there anything in the proposal that is not clear? | > - What change could be made to this proposal to make it more effective? | > | > Please find the text of the proposal below. | > | > Kind Regards, | > | > Andy and Masato | > | > | > | > | ---------------------------------------------------------------------- | > prop-111-v004 Request-based expansion of IPv6 default allocation size | > | ---------------------------------------------------------------------- | > | > Author: Tomohiro Fujisaki | > fujisaki@syce.net mailto:fujisaki@syce.net | > | > | > 1. Problem statement | > -------------------- | > | > IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6 | > address allocation and assignment policy"[1]. It's better to | > expand this minimum allocation size up to /29 (/32 - /29) since: | > | > - Before sparse allocation mechanism implemented in late 2006, /29 | > was reserved for all /32 allocations by sequential allocation | > method made from those old /23 blocks. These reserved blocks | > might be kept unused in the future. | > | > - Sparse allocation mechanism was implemented in late 2006 with a | > /12 allocation from the IANA. Under the sparse allocation | > mechanism, there is no reservation size defined, and the space | > between allocations continues to change, depending on the | > remaining free pool available in APNIC. | > | > However, the "APNIC guidelines for IPv6 allocation and | > assignment requests"[2] stated: | > | > "In accordance with APNIC's "IPv6 address allocation and | > assignment policy", where possible, subsequent delegations to the | > same resource holder are made from an adjacent address block by | > growing the delegation into the free space remaining, unless | > disaggregated ranges are requested for multiple discrete | > networks." | > | > So, it is expected that allocation up to /29 is guaranteed for | > consistency with allocations above. Based on the current | > situation, contiguous allocation of /29 can still be accommodated | > even under the sparse allocation mechanism (Current /32 | > allocations from the /12 block can grow up to /24 at this stage). | > | > - After amended HD Ratio (0.94) and base calculation size (/56) was | > introduced (prop-031 and prop-033), to obtain address blocks larger | > than /32 and to request additional address blocks became harder | > especially for small and middle size ISPs. | > | > - For traffic control purpose, some LIRs announce address blocks | > longer than /32 (e.g. /35). However, some ISPs may set filters to | > block address size longer than /32 since some filtering | > guidelines recommend to filter longer prefix than /32([3][4]). If | > LIRs have multiple /32, they can announce these blocks and its | > reachability will be better than longer prefix. | > | > - If an LIR needs address blocks larger than /32, LIRs may tend to | > announce as a single prefix if a /29 is allocated initially at | > once. i.e., total number of announced prefixes in case 1 may be | > smaller than in case 2. | > | > case 1: | > The LIR obtains /29 at the beginning of IPv6 network construction. | > | > case 2: | > The LIR obtains /32, and /31, /30 additionally with the subsequent | > allocation mechanism. | > | > 2. Objective of policy change | > ----------------------------- | > | > This proposal modifies the eligibility for an organization to | > receive or extend an IPv6 address space up to a /29 (/32 -/29) by | > explaining how the extended space up to /29 will be used. | > | > | > 3. Situation in other regions | > ----------------------------- | > | > RIPE-NCC: | > The policy "Extension of IPv6 /32 to /29 on a per-allocation vs | > per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get | > up to /29 by default. | > | > | > 4. Proposed policy solution | > ---------------------------- | > | > - Change the text to "5.2.2 Minimum initial allocation size" of | > current policy document as below: | > | > Organizations that meet the initial allocation criteria are | > eligible to receive an initial allocation of /32. The organizations | > can receive up to /29 by providing utilization information of the | > whole | > address space. | > | > - Change /32 to /29 in "5.2.3 Larger initial allocations" | > | > Initial allocations larger than /29 may be justified if: | > | > - Add following text as 5.3.4 | > | > 5.3.4 Extend existing allocations to /29 | > LIRs that hold one or more IPv6 allocations are able to request | > extension of each of these allocations up to a /29 without meeting | > the utilization rate for subsequent allocation by providing their | > network | > plan to show how the whole address space will be used. | > | > | > 5. Explain the advantages of the proposal | > ----------------------------------------- | > | > - It is possible to utilize address blocks which is potentially | > unused into the future. | > | > - Organizations can design their IPv6 networks more flexibly. | > | > - It will be possible for LIRs to control traffic easier. | > | > | > 6. Explain the disadvantages of the proposal | > -------------------------------------------- | > | > Some people may argue this will lead to inefficient utilization of | > IPv6 space since LIRs can obtain huge address size unnecessarily. | > However, this will not happen because larger address size needs | > higher cost to maintain that address block. | > | > | > 7. Impact on resource holders | > ----------------------------- | > | > NIRs must implement this policy if it is implemented by APNIC. | > | > | > 8. References (if required) | > --------------------------- | > | > [1] IPv6 address allocation and assignment policy | > http://www.apnic.net/policy/ipv6-address-policy | > | > [2] APNIC guidelines for IPv6 allocation and assignment requests | > https://www.apnic.net/publications/media-library/documents/resource-guidelin... | > | > [3] Packet Filter and Route Filter Recommendation for IPv6 at xSP | > routers | > https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendat... | > | > [4] IPv6 BGP filter recommendations | > http://www.space.net/~gert/RIPE/ipv6-filters.html | > http://www.space.net/%7Egert/RIPE/ipv6-filters.html | > | > | > | > * 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 |
Activity Summary
- 3187 days inactive
- 3187 days old
- sig-policy@lists.apnic.net
- 5 participants
- 6 comments