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 following proposal, "IPv6 address allocation for deployment purposes," has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 30.
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 policy proposal is available at:
http://www.apnic.net/policy/proposals/prop-087
randy, Ching-Heng, and Terence
________________________________________________________________________
prop-087-v001: IPv6 address allocation for deployment purposes ________________________________________________________________________
Author: Tomohiro Fujisaki fujisaki@syce.net
Version: 1
Date: 26 July 2010
1. Introduction ----------------
This is a proposal to add alternative criteria for receiving a larger than /32 initial IPv6 allocation during the initial IPv6 deployment phase (from now until 2013). Under this proposal, a network can justify more than a /32 if the network is using deployment protocol described in a RFC.
2. Summary of the current problem ----------------------------------
Current IPv6 address allocation policy is basically based on number of subscribers the applicant will have [1], but this does not allow sufficient allocation size to adequately deploy some IPv6 protocols. For example, the "6rd" protocol needs more than /32 to implement adequately in an ISP network due to technical reasons [2]. Therefore, criteria to allow allocations based on technical justification is necessary.
3. Situation in other RIRs ---------------------------
ARIN has two related draft policies under discussion:
2010-9: IPv6 for 6rd https://www.arin.net/policy/proposals/2010_9.html
2010-12: IPv6 Subsequent Allocation https://www.arin.net/policy/proposals/2010_12.html
RIPE has discussed the possibility of a policy proposal for 6rd, but no formal proposal has yet been submitted.
There has been no similar discussion in AfriNIC or LACNIC.
4. Details -----------
This proposal contains two phases:
1. IPv6 deployment phase (now until 2013) 2. After the deployment phase
It is proposed that:
4.1 In the IPv6 deployment phase (til 2013), networks using an IPv6 deployment protocol specified in an Standard track RFC are eligible for initial allocations larger than a /32.
Requestors must specifically refer to the deployment protocol they are using and the number of the RFC describing it.
4.2 After the deployment phase ends, networks that have received an allocation under the criteria described in section 4.1 above must demonstrate the usage of that address space.
- If the network can justify continued use of the larger than /32 address allocation by demonstrating it is in accordance with the HD-Ratio based utilization policy, the network may keep the entire address block.
- If the network cannot demonstrate that it is in accordance with the HD-Ratio based utilization policy, it will need to return the excess portion of its address block to APNIC.
5. Pros/Cons -------------
Advantages:
- This proposed policy makes it easier to implement a IPv6 network. For example, new deployment protocols such as "6rd" can be implemented easily with this proposal.
Disadvantages:
- Some deployment protocols need IPv6 address blocks larger than current criteria and this might waste IPv6 addresses.
6. Effect on APNIC -------------------
APNIC members can obtain larger IPv6 address blocks for IPv6 deployment.
7. Effect on NIRs ------------------
NIRs can select to implement this proposal or not.
8. References --------------
[1] See section 5.2, "Initial allocation" in "IPv6 address allocation and assignment policy" http://www.apnic.net/policy/ipv6-address-policy#5.2.3
[2] See section 11, "IPv6 Address Space Usage" in "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)" http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd-10#section-11
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Fujisakisan,
Clarifying question. Can you explain why Section 5.2.3 a. of the current allocation policy is not good enough to address needs for an allocation greater than /32?
Regards, Seiichi
Randy Bush wrote:
Dear SIG members,
The following proposal, "IPv6 address allocation for deployment purposes," has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 30.
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 policy proposal is available at:
http://www.apnic.net/policy/proposals/prop-087randy, Ching-Heng, and Terence
prop-087-v001: IPv6 address allocation for deployment purposes ________________________________________________________________________
Author: Tomohiro Fujisaki fujisaki@syce.net
Version: 1
Date: 26 July 2010
- Introduction
This is a proposal to add alternative criteria for receiving a larger than /32 initial IPv6 allocation during the initial IPv6 deployment phase (from now until 2013). Under this proposal, a network can justify more than a /32 if the network is using deployment protocol described in a RFC.
- Summary of the current problem
Current IPv6 address allocation policy is basically based on number of subscribers the applicant will have [1], but this does not allow sufficient allocation size to adequately deploy some IPv6 protocols. For example, the "6rd" protocol needs more than /32 to implement adequately in an ISP network due to technical reasons [2]. Therefore, criteria to allow allocations based on technical justification is necessary.
- Situation in other RIRs
ARIN has two related draft policies under discussion:
2010-9: IPv6 for 6rd https://www.arin.net/policy/proposals/2010_9.html 2010-12: IPv6 Subsequent Allocation https://www.arin.net/policy/proposals/2010_12.htmlRIPE has discussed the possibility of a policy proposal for 6rd, but no formal proposal has yet been submitted.
There has been no similar discussion in AfriNIC or LACNIC.
- Details
This proposal contains two phases:
1. IPv6 deployment phase (now until 2013) 2. After the deployment phaseIt is proposed that:
4.1 In the IPv6 deployment phase (til 2013), networks using an IPv6 deployment protocol specified in an Standard track RFC are eligible for initial allocations larger than a /32.
Requestors must specifically refer to the deployment protocol they are using and the number of the RFC describing it.4.2 After the deployment phase ends, networks that have received an allocation under the criteria described in section 4.1 above must demonstrate the usage of that address space.
- If the network can justify continued use of the larger than /32 address allocation by demonstrating it is in accordance with the HD-Ratio based utilization policy, the network may keep the entire address block. - If the network cannot demonstrate that it is in accordance with the HD-Ratio based utilization policy, it will need to return the excess portion of its address block to APNIC.
- Pros/Cons
Advantages:
- This proposed policy makes it easier to implement a IPv6 network. For example, new deployment protocols such as "6rd" can be implemented easily with this proposal.Disadvantages:
- Some deployment protocols need IPv6 address blocks larger than current criteria and this might waste IPv6 addresses.
- Effect on APNIC
APNIC members can obtain larger IPv6 address blocks for IPv6 deployment.
- Effect on NIRs
NIRs can select to implement this proposal or not.
- References
[1] See section 5.2, "Initial allocation" in "IPv6 address allocation and assignment policy" http://www.apnic.net/policy/ipv6-address-policy#5.2.3
[2] See section 11, "IPv6 Address Space Usage" in "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)" http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd-10#section-11
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 Kawamura-san,
Thank you for your question, and I'm so sorry replying so late.
From: Seiichi Kawamura kawamucho@mesh.ad.jp Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes Date: Thu, 29 Jul 2010 23:44:42 +0900
| -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA1 | | Fujisakisan, | | Clarifying question. | Can you explain why Section 5.2.3 a. of the | current allocation policy is not good enough | to address needs for an allocation greater | than /32?
Current policy http://www.apnic.net/policy/ipv6-address-policy says:
5.2.3 Larger initial allocations
Initial allocations larger than /32 may be justified if:
//snip
In either case, an allocation will be made which fulfills the calculated address requirement, in accordance with the HD-Ratio based utilization policy.
So, if you need an address block larger than /32, you have to fulfills the HD-Ratio based policy.
In the case to get /28, which I think reasonable block size for 6rd network deployment (/60 per user network and embedding /32 IPv4 address), you have to justify to have over /29 HD-ratio based number of users, which is 43,665,787.
P 56-P Total /56s Threshold Util% 29 27 134,217,728 43,665,787 32.5
The HD-ratio table is on the same policy document , section 7.
Even if you have a plan to assign /48 to each customer, you have to justify 170,569 = 43,665,787/256 IPv6 users.
# Please correct me if my understanding is wrong!
I think these numbers are hard to justify, and it might be better to define another parameters to get larger block size. For example, in 6rd case, parameters to define total address block size are not number of users and user's network size, but embedding IPv4 prefix size and user's network size.
Does this explanation answer you?
Yours Sincerely, -- Tomohiro Fujisaki
I think any deployment decision should be done within the confines of the available resources, IP addresses included. If one does not have the justification and v6 addresses to deploy 6rd, then one should consider a different deployment approach, not the other way around.
Any thoughts?
yi
----- Original Message ---- From: Randy Bush randy@psg.com To: Policy SIG sig-policy@apnic.net Sent: Mon, July 26, 2010 4:45:50 AM Subject: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes
Dear SIG members,
The following proposal, "IPv6 address allocation for deployment purposes," has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 30.
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 policy proposal is available at:
http://www.apnic.net/policy/proposals/prop-087
randy, Ching-Heng, and Terence
________________________________________________________________________
prop-087-v001: IPv6 address allocation for deployment purposes ________________________________________________________________________
Author: Tomohiro Fujisaki fujisaki@syce.net
Version: 1
Date: 26 July 2010
1. Introduction ----------------
This is a proposal to add alternative criteria for receiving a larger than /32 initial IPv6 allocation during the initial IPv6 deployment phase (from now until 2013). Under this proposal, a network can justify more than a /32 if the network is using deployment protocol described in a RFC.
2. Summary of the current problem ----------------------------------
Current IPv6 address allocation policy is basically based on number of subscribers the applicant will have [1], but this does not allow sufficient allocation size to adequately deploy some IPv6 protocols. For example, the "6rd" protocol needs more than /32 to implement adequately in an ISP network due to technical reasons [2]. Therefore, criteria to allow allocations based on technical justification is necessary.
3. Situation in other RIRs ---------------------------
ARIN has two related draft policies under discussion:
2010-9: IPv6 for 6rd https://www.arin.net/policy/proposals/2010_9.html
2010-12: IPv6 Subsequent Allocation https://www.arin.net/policy/proposals/2010_12.html
RIPE has discussed the possibility of a policy proposal for 6rd, but no formal proposal has yet been submitted.
There has been no similar discussion in AfriNIC or LACNIC.
4. Details -----------
This proposal contains two phases:
1. IPv6 deployment phase (now until 2013) 2. After the deployment phase
It is proposed that:
4.1 In the IPv6 deployment phase (til 2013), networks using an IPv6 deployment protocol specified in an Standard track RFC are eligible for initial allocations larger than a /32.
Requestors must specifically refer to the deployment protocol they are using and the number of the RFC describing it.
4.2 After the deployment phase ends, networks that have received an allocation under the criteria described in section 4.1 above must demonstrate the usage of that address space.
- If the network can justify continued use of the larger than /32 address allocation by demonstrating it is in accordance with the HD-Ratio based utilization policy, the network may keep the entire address block.
- If the network cannot demonstrate that it is in accordance with the HD-Ratio based utilization policy, it will need to return the excess portion of its address block to APNIC.
5. Pros/Cons -------------
Advantages:
- This proposed policy makes it easier to implement a IPv6 network. For example, new deployment protocols such as "6rd" can be implemented easily with this proposal.
Disadvantages:
- Some deployment protocols need IPv6 address blocks larger than current criteria and this might waste IPv6 addresses.
6. Effect on APNIC -------------------
APNIC members can obtain larger IPv6 address blocks for IPv6 deployment.
7. Effect on NIRs ------------------
NIRs can select to implement this proposal or not.
8. References --------------
[1] See section 5.2, "Initial allocation" in "IPv6 address allocation and assignment policy" http://www.apnic.net/policy/ipv6-address-policy#5.2.3
[2] See section 11, "IPv6 Address Space Usage" in "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)" http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd-10#section-11 * 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 Yi,
Thank you for your comment.
| I think any deployment decision should be done within the confines of the | available resources, IP addresses included. If one does not have the | justification and v6 addresses to deploy 6rd, then one should consider a | different deployment approach, not the other way around. | | Any thoughts?
I can see what you're saying, but in that sense, large address block holders (maybe large ISPs) can use any deployment protocols but small ISPs can use only limited deployment protocols. I think address block size should not become a limitation to select deployment protocols, especially in the IPv6 deployment phase (so I added a condition this proposal is for a limited time only).
Yours Sincerely, -- Tomohiro Fujisaki
My problem with 'limited time' clause is that 1) I doubt APNIC has the resource to check/audit 2) if you have one account using the 6rd, you probably would not tear down the 6rd address block and return it to APNIC
I doubt APNIC has been successful at reclaim back IP allocations. I worry that would be another 'legacy/historic block'.
yi
----- Original Message ---- From: "fujisaki@syce.net" fujisaki@syce.net To: yi_chu_01@yahoo.com Cc: sig-policy@apnic.net Sent: Fri, August 6, 2010 3:55:57 AM Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes
Hi Yi,
Thank you for your comment.
| I think any deployment decision should be done within the confines of the | available resources, IP addresses included. If one does not have the | justification and v6 addresses to deploy 6rd, then one should consider a | different deployment approach, not the other way around. | | Any thoughts?
I can see what you're saying, but in that sense, large address block holders (maybe large ISPs) can use any deployment protocols but small ISPs can use only limited deployment protocols. I think address block size should not become a limitation to select deployment protocols, especially in the IPv6 deployment phase (so I added a condition this proposal is for a limited time only).
Yours Sincerely, -- Tomohiro Fujisaki
Hi Yi,
I doubt APNIC has been successful at reclaim back IP allocations.
I do not think so.
APNIC has successfully reclaimed the block for the experiment of the large space global IP address usage back to the public pool in the past. If APNIC and APNIC community properly check their activity of the 6rd, then the block would not be a give-away.
Kosuke
On Fri, 6 Aug 2010 08:46:04 -0700 (PDT) Yi Chu yi_chu_01@yahoo.com wrote:
My problem with 'limited time' clause is that 1) I doubt APNIC has the resource to check/audit 2) if you have one account using the 6rd, you probably would not tear down the 6rd address block and return it to APNIC
I doubt APNIC has been successful at reclaim back IP allocations. I worry that would be another 'legacy/historic block'.
yi
----- Original Message ---- From: "fujisaki@syce.net" fujisaki@syce.net To: yi_chu_01@yahoo.com Cc: sig-policy@apnic.net Sent: Fri, August 6, 2010 3:55:57 AM Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes
Hi Yi,
Thank you for your comment.
| I think any deployment decision should be done within the confines of the | available resources, IP addresses included. If one does not have the | justification and v6 addresses to deploy 6rd, then one should consider a | different deployment approach, not the other way around. | | Any thoughts?
I can see what you're saying, but in that sense, large address block holders (maybe large ISPs) can use any deployment protocols but small ISPs can use only limited deployment protocols. I think address block size should not become a limitation to select deployment protocols, especially in the IPv6 deployment phase (so I added a condition this proposal is for a limited time only).
Yours Sincerely,
Tomohiro Fujisaki
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 Yi and Kosuke-san,
Thank you so much for your reply.
The point Yi mentioned was almost same as that of pointed out at policy meeting in Japan.
My problem with 'limited time' clause is that
- I doubt APNIC has the resource to check/audit
I believe with a same scheme in the current IP address request (in this case, the initial IPv6 address request larger than /32), it's possible to check the resource.
- if you have one account using the 6rd, you probably would not
tear down the 6rd address block and return it to APNIC
I think this is ISP's risk, and they have to consider how to handle such cases (this is operational issue, not policy issue, I think).
Yours Sincerely, -- Tomohiro Fujisaki
From: Kosuke Ito kosuke@bugest.net Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes Date: Sun, 8 Aug 2010 22:15:26 +0900
| Hi Yi, | | > I doubt APNIC has been successful at reclaim back IP allocations. | | I do not think so. | | APNIC has successfully reclaimed the block for the experiment | of the large space global IP address usage back to the public | pool in the past. | If APNIC and APNIC community properly check their activity of | the 6rd, then the block would not be a give-away. | | Kosuke | | | On Fri, 6 Aug 2010 08:46:04 -0700 (PDT) | Yi Chu yi_chu_01@yahoo.com wrote: | | > My problem with 'limited time' clause is that 1) I doubt APNIC has the resource | > to check/audit 2) if you have one account using the 6rd, you probably would not | > tear down the 6rd address block and return it to APNIC | > | > I doubt APNIC has been successful at reclaim back IP allocations. I worry that | > would be another 'legacy/historic block'. | > | > yi | > | > | > | > ----- Original Message ---- | > From: "fujisaki@syce.net" fujisaki@syce.net | > To: yi_chu_01@yahoo.com | > Cc: sig-policy@apnic.net | > Sent: Fri, August 6, 2010 3:55:57 AM | > Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment | > purposes | > | > | > Hi Yi, | > | > Thank you for your comment. | > | > | I think any deployment decision should be done within the confines of the | > | available resources, IP addresses included. If one does not have the | > | justification and v6 addresses to deploy 6rd, then one should consider a | > | different deployment approach, not the other way around. | > | | > | Any thoughts? | > | > I can see what you're saying, but in that sense, large address block | > holders (maybe large ISPs) can use any deployment protocols but small | > ISPs can use only limited deployment protocols. I think address block | > size should not become a limitation to select deployment protocols, | > especially in the IPv6 deployment phase (so I added a condition | > this proposal is for a limited time only). | > | > Yours Sincerely, | > -- | > Tomohiro Fujisaki | > | > | > | > | > * 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 | | | -- | Kosuke Ito <kosuke[at]bugest.net> | | * 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 | |
Some comments, to maybe help clarify discussion so far...
prop-087-v001: IPv6 address allocation for deployment purposes ________________________________________________________________________
Author: Tomohiro Fujisaki fujisaki@syce.net
Version: 1
Date: 26 July 2010
- Summary of the current problem
Current IPv6 address allocation policy is basically based on number of subscribers the applicant will have [1], but this does not allow sufficient allocation size to adequately deploy some IPv6 protocols. For example, the "6rd" protocol needs more than /32 to implement adequately in an ISP network due to technical reasons [2].
Reference [2] does not say that 6rd needs more than a /32 for implementation.
It says that it needs more than a /32 should the ISP want to encode the entire IPv4 address the customer uses.
How many ISPs use the entire IPv4 address space for their customer public address space?
I think the answer is none. ;-)
So using 6rd as a justification for getting more than a /32 seems rather surprising to me.
Perhaps the proposal would benefit from an explanation as to why (technically and operationally) the entire IPv4 address needs to be encoded, rather than, say the final 16 bits which would still give the end user an entire /48 to play with. Even an ISP who uses an IPv4 /8 for customer facing addresses can still give each customer a /56. And even if they had an IPv4 /8, they could in theory use that to justify /24 worth of IPv6 address space - which would then let them encode the entire IPv4 address for 6rd to give each customer a /56 - or the final 24 bits to give the customer a /48. Etc.
philip --
Hi Philip,
Thank you for your reply.
| > ---------------------------------- | > | > Current IPv6 address allocation policy is basically based on number of | > subscribers the applicant will have [1], but this does not allow | > sufficient allocation size to adequately deploy some IPv6 | > protocols. For example, the "6rd" protocol needs more than /32 to | > implement adequately in an ISP network due to technical reasons | > [2]. | | Reference [2] does not say that 6rd needs more than a /32 for | implementation. | | It says that it needs more than a /32 should the ISP want to encode the | entire IPv4 address the customer uses. | | How many ISPs use the entire IPv4 address space for their customer | public address space? | | I think the answer is none. ;-)
I'm sorry if I misunderstand your comment, but the problem is not number of addresses but prefixes of the addresses.
If ISPs use a same address prefix for all users, it is possible to shorten the encoded prefix. I'm not sure how many ISPs request and get additional address blocks under same IPv4 address prefixes, but I suppose there are not so many ISPs that use a single prefix for all of their customers.
| So using 6rd as a justification for getting more than a /32 seems rather | surprising to me. | | Perhaps the proposal would benefit from an explanation as to why | (technically and operationally) the entire IPv4 address needs to be | encoded, rather than, say the final 16 bits which would still give the | end user an entire /48 to play with. Even an ISP who uses an IPv4 /8 for | customer facing addresses can still give each customer a /56. And even | if they had an IPv4 /8, they could in theory use that to justify /24 | worth of IPv6 address space - which would then let them encode the | entire IPv4 address for 6rd to give each customer a /56 - or the final | 24 bits to give the customer a /48. Etc.
OK, I'll try to explain this point in my proposed text or presentation materials.
One request to APNIC Secretariat, could you show the allocation statistics that how many IPv4 address holders obtain addinional address blocks, and if possible, how may multiple IPv4 address block holders above got same IPv4 address prefixes? (e.g. initial address is 1.0.0.0/22 and additonal address is also under 1.0.0.0/8)
Yours Sincerely, -- Tomohiro Fujisaki
Dear all,
I think Fujisaki-san's proposal aims to encourage IPv6 deployment.
Then the point is APNIC should allocate with technical reason or not, when some company wants to deploy IPv6 with the technology which needs bigger IPv6 addresses.
I know technical or operational issue should be disscussed carefully. *For IPv6 deployment purpose*, I support this propsal. Because, this propsal defines the period, it lessens the waste of IPv6 address.
Regards, Norisuke HIRAI
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Randy Bush Sent: Monday, July 26, 2010 5:46 PM To: Policy SIG Subject: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes
Dear SIG members,
The following proposal, "IPv6 address allocation for deployment purposes," has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 30.
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 policy proposal is available at:
http://www.apnic.net/policy/proposals/prop-087
randy, Ching-Heng, and Terence
________________________________________________________________________
prop-087-v001: IPv6 address allocation for deployment purposes ________________________________________________________________________
Author: Tomohiro Fujisaki fujisaki@syce.net
Version: 1
Date: 26 July 2010
1. Introduction ----------------
This is a proposal to add alternative criteria for receiving a larger than /32 initial IPv6 allocation during the initial IPv6 deployment phase (from now until 2013). Under this proposal, a network can justify more than a /32 if the network is using deployment protocol described in a RFC.
2. Summary of the current problem ----------------------------------
Current IPv6 address allocation policy is basically based on number of subscribers the applicant will have [1], but this does not allow sufficient allocation size to adequately deploy some IPv6 protocols. For example, the "6rd" protocol needs more than /32 to implement adequately in an ISP network due to technical reasons [2]. Therefore, criteria to allow allocations based on technical justification is necessary.
3. Situation in other RIRs ---------------------------
ARIN has two related draft policies under discussion:
2010-9: IPv6 for 6rd https://www.arin.net/policy/proposals/2010_9.html
2010-12: IPv6 Subsequent Allocation https://www.arin.net/policy/proposals/2010_12.html
RIPE has discussed the possibility of a policy proposal for 6rd, but no formal proposal has yet been submitted.
There has been no similar discussion in AfriNIC or LACNIC.
4. Details -----------
This proposal contains two phases:
1. IPv6 deployment phase (now until 2013) 2. After the deployment phase
It is proposed that:
4.1 In the IPv6 deployment phase (til 2013), networks using an IPv6 deployment protocol specified in an Standard track RFC are eligible for initial allocations larger than a /32.
Requestors must specifically refer to the deployment protocol they are using and the number of the RFC describing it.
4.2 After the deployment phase ends, networks that have received an allocation under the criteria described in section 4.1 above must demonstrate the usage of that address space.
- If the network can justify continued use of the larger than /32 address allocation by demonstrating it is in accordance with the HD-Ratio based utilization policy, the network may keep the entire address block.
- If the network cannot demonstrate that it is in accordance with the HD-Ratio based utilization policy, it will need to return the excess portion of its address block to APNIC.
5. Pros/Cons -------------
Advantages:
- This proposed policy makes it easier to implement a IPv6 network. For example, new deployment protocols such as "6rd" can be implemented easily with this proposal.
Disadvantages:
- Some deployment protocols need IPv6 address blocks larger than current criteria and this might waste IPv6 addresses.
6. Effect on APNIC -------------------
APNIC members can obtain larger IPv6 address blocks for IPv6 deployment.
7. Effect on NIRs ------------------
NIRs can select to implement this proposal or not.
8. References --------------
[1] See section 5.2, "Initial allocation" in "IPv6 address allocation and assignment policy" http://www.apnic.net/policy/ipv6-address-policy#5.2.3
[2] See section 11, "IPv6 Address Space Usage" in "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)" http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd-10#section-11 * 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
- 4845 days inactive
- 4845 days old
- sig-policy@lists.apnic.net
- 7 participants
- 10 comments