[arin-ppml] Updated 6rd proposal for ATLN conference
Azinger, Marla
Marla.Azinger at FTR.com
Thu Sep 23 17:52:58 EDT 2010
The 6rd proposal has been updated to satisfy ARIN staff questions and input
Changes made:
1. relocated explanatory info into the Rational
2. Added justification guidelines to the Rational
3. Removed verbage that was unnessary and unfairly limiting to anyone wishing to use 6rd
4. Included explanation for contiguous theory
5. Added management of IP space details
6. Clarified the review and reclamation process
7. Added references and research support
Revised version
Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
1. Policy Proposal Name: IPv6 for 6rd (RFC 5969)
2. Proposal Originator
1. name:Marla Azinger
2. email:marla.azinger at frontiercorp.com
3. telephone:585-413-9128
4. organization:Frontier Communications
1. name:Mark Townsley
2. email:townsley at cisco.com
3. telephone:+33-1-5804-3483
4. organization:Cisco Systems
1. name:Alain Durand
2. email:adurand at juniper.net
3. telephone:215-908-4848
4. organization:Juniper Networks
3. Proposal Version:1
4. Date:25 March 2010
5. Proposal type:NEW
6. Policy term:permanent
7. Policy statement:
6rd is an incremental method for Service Providers to deploy IPv6, defined in the IETF Standards Track RFC 5969.
If you have IPv4 addresses then you automatically qualify for IPv6 space for 6rd. Upon receipt of a 6rd request, an appropriate additional IPv6
allocation will be made that supports 6rd to be counted as a separate & parallel deployment to IPv4 and native IPv6. There is no requirement to
segregate address space requested under this policy from regular IPv6 Allocation Supernets. From a management perspective this address space is to be
treated as regular IPv6 address space.
While it is possible for an operator to transition to native IPv6 within the same address space used by 6rd, some operators may wish to keep native IPv6
users separate from 6rd users to permit optimization of aggregation. If an operator chooses to renumber users to an address space outside the 6rd
aggregate when transitioning them to native IPv6, the 6rd allocation may be returned to ARIN when it is no longer in use.
It is suggested that contiguous allocations be made to any prior existing ones in the event justification for more IPv6 address space exists when the
organization transitions 6rd out of their network.
Justification for use of IPv6 for 6rd will be reviewed after the first 3 years and reclaimed if it is not in use. After the first 3 years, any
additional reviews will follow regular IPv6 policy. Requester will be exempt from returning all or a portion of the address space when 6rd is no longer
used if they can show justification for need of the 6rd address space for other existing IPv6 addressing requirements be it native IPv6 or some other
IPv6 network technology.
8. Rationale:
6rd is an incremental method for Service Providers to deploy IPv6, defined in the IETF Standards Track RFC 5969. 6rd has been used successfully by a
number of service providers to deploy IPv6 based on automatic IPv6 prefix delegation and tunneling over existing IPv4 infrastructure. The chief
advantage of this approach is that it deploys the service quickly while enabling the network administration to manage its deployment outlays, and
ensures the correspondence between IPv4 and
IPv6 routing. 6rd is distinct from other transition technologies such as
6to4 and Teredo in that it operates within the confines of a service provider network, allowing it to be managed by the service provider. 6rd is
designed to be transparent to both the user and the rest of the Internet at large.
To allow automatic prefix delegation to sites and stateless tunneling, 6rd utilizes a mapping scheme between an operator's IPv6 allocation and
IPv4 address space. With a /32 allocation and non-contiguous IPv4 addressing plan, IPv6 deployment with 6rd is possible, but generally results in no
more than a /64 to a subscriber site. A /28 allows the operator to delegate prefixes shorter than /64, allowing multiple /64 subnets within the home.
When IPv4 addresses are known to be contiguous for the lifetime of the 6rd deployment, mechanisms exist for a more efficient mapping. This is most
likely if the operator has deployed IPv4 NAPT technology within their network, and are addressing homes within a contiguous block of RFC 1918 space
(e.g., 10/8).
This example shows how the 6rd prefix is created based on a /28 IPv6 prefix using one of several non-contiguous global address ranges. This is a more
realistic scenario of service providers in North America deploying IPv6 with 6rd today:
SP IPv6 prefix: 2001:0DB0::/28
v4suffix-length: 32 (unable to exclude common bits
due to non-contiguous IPv4 allocations)
6rd CE router IPv4 address: 192.0.2.1
6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60
This example shows how the 6rd prefix is created based on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8. This example assumes the
operator is facing IPv4 scarcity to the point it has deployed or is planning to deploy a layer of NAPT ("Carrier Grade NAT") within the service provider
network and addressed its subscribers with private addresses accordingly:
SP IPv6 prefix: 2001:0DB8::/32
v4suffix-length: 24 (from 10/8, first octet (10) is excluded
from the encoding)
6rd CE router IPv4 address: 10.100.100.1
6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
Justifications: Examples of how to display home networks using multiple subnets is accomplished by providing a network plan that involves the use of
routing opposed to bridging. Such plans may involve the reduction of NAT, next-gen services, media types, separate L2 domains and more. The plan must
simply show how the end user environment is not a single LAN subscriber.
Supporting Research: 6rd is responsible for the largest production Ipv6 deployment today, supporting 4.5 million subscribers in France within a
/26 that was granted by RIPE. This ISP previously had a /32, and went back and to RIPE for an additional /26. At least one other provider has deployed
6rd within a /27 that was granted recently for 6rd. A /24 was recently granted as well, likely for 6rd deployment. There are multiple providers in
North America and around the world that have committed to delivering residential broadband service with 6rd, or are doing so today.
The following RIPE report shows the affect 6rd has had in France, which accounts for the largest deployment in all of Europe or North America.
http://labs.ripe.net/Members/emileaben/content-measuring-ipv6-web-clients-and-caching-resolvers-part-2-country-level-and-other-statistics
"In Figure 2 (Western Europe), we see a native IPv6 client capability in France of over 4%. This is mainly caused by free.fr that accounts for 70% of
the native IPv6 clients measured. Note that technically free.fr uses 6rd-tunneling, but externally that looks, feels and smells like native IPv6"
9. Timetable for implementation:Immediate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100923/295ab178/attachment.htm>
-------------- next part --------------
Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
1. Policy Proposal Name: IPv6 for 6rd (RFC 5969)
2. Proposal Originator
1. name:Marla Azinger
2. email:marla.azinger at frontiercorp.com
3. telephone:585-413-9128
4. organization:Frontier Communications
1. name:Mark Townsley
2. email:townsley at cisco.com
3. telephone:+33-1-5804-3483
4. organization:Cisco Systems
1. name:Alain Durand
2. email:adurand at juniper.net
3. telephone:215-908-4848
4. organization:Juniper Networks
3. Proposal Version:1
4. Date:25 March 2010
5. Proposal type:NEW
6. Policy term:permanent
7. Policy statement:
6rd is an incremental method for Service Providers to deploy IPv6, defined in the IETF Standards Track RFC 5969.
If you have IPv4 addresses then you automatically qualify for IPv6 space for 6rd. Upon receipt of a 6rd request, an appropriate additional IPv6 allocation will be made that supports 6rd to be counted as a separate & parallel deployment to IPv4 and native IPv6. There is no requirement to segregate address space requested under this policy from regular IPv6 Allocation Supernets. From a management perspective this address space is to be treated as regular IPv6 address space.
While it is possible for an operator to transition to native IPv6 within the same address space used by 6rd, some operators may wish to keep native IPv6 users separate from 6rd users to permit optimization of aggregation. If an operator chooses to renumber users to an address space outside the 6rd aggregate when transitioning them to native IPv6, the 6rd allocation may be returned to ARIN when it is no longer in use.
It is suggested that contiguous allocations be made to any prior existing ones in the event justification for more IPv6 address space exists when the organization transitions 6rd out of their network.
Justification for use of IPv6 for 6rd will be reviewed after the first 3 years and reclaimed if it is not in use. After the first 3 years, any additional reviews will follow regular IPv6 policy. Requester will be exempt from returning all or a portion of the address space when 6rd is no longer used if they can show justification for need of the 6rd address space for other existing IPv6 addressing requirements be it native IPv6 or some other IPv6 network technology.
8. Rationale:
6rd is an incremental method for Service Providers to deploy IPv6, defined in the IETF Standards Track RFC 5969. 6rd has been used successfully by a number of service providers to deploy IPv6 based on automatic IPv6 prefix delegation and tunneling over existing IPv4 infrastructure. The chief advantage of this approach is that it deploys the service quickly while enabling the network administration to manage its deployment outlays, and ensures the correspondence between IPv4 and
IPv6 routing. 6rd is distinct from other transition technologies such as
6to4 and Teredo in that it operates within the confines of a service provider network, allowing it to be managed by the service provider. 6rd is designed to be transparent to both the user and the rest of the Internet at large.
To allow automatic prefix delegation to sites and stateless tunneling, 6rd utilizes a mapping scheme between an operator's IPv6 allocation and
IPv4 address space. With a /32 allocation and non-contiguous IPv4 addressing plan, IPv6 deployment with 6rd is possible, but generally results in no more than a /64 to a subscriber site. A /28 allows the operator to delegate prefixes shorter than /64, allowing multiple /64 subnets within the home. When IPv4 addresses are known to be contiguous for the lifetime of the 6rd deployment, mechanisms exist for a more efficient mapping. This is most likely if the operator has deployed IPv4 NAPT technology within their network, and are addressing homes within a contiguous block of RFC 1918 space (e.g., 10/8).
This example shows how the 6rd prefix is created based on a /28 IPv6 prefix using one of several non-contiguous global address ranges. This is a more realistic scenario of service providers in North America deploying IPv6 with 6rd today:
SP IPv6 prefix: 2001:0DB0::/28
v4suffix-length: 32 (unable to exclude common bits
due to non-contiguous IPv4 allocations)
6rd CE router IPv4 address: 192.0.2.1
6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60
This example shows how the 6rd prefix is created based on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8. This example assumes the operator is facing IPv4 scarcity to the point it has deployed or is planning to deploy a layer of NAPT ("Carrier Grade NAT") within the service provider network and addressed its subscribers with private addresses accordingly:
SP IPv6 prefix: 2001:0DB8::/32
v4suffix-length: 24 (from 10/8, first octet (10) is excluded
from the encoding)
6rd CE router IPv4 address: 10.100.100.1
6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
Justifications: Examples of how to display home networks using multiple subnets is accomplished by providing a network plan that involves the use of routing opposed to bridging. Such plans may involve the reduction of NAT, next-gen services, media types, separate L2 domains and more. The plan must simply show how the end user environment is not a single LAN subscriber.
Supporting Research: 6rd is responsible for the largest production Ipv6 deployment today, supporting 4.5 million subscribers in France within a
/26 that was granted by RIPE. This ISP previously had a /32, and went back and to RIPE for an additional /26. At least one other provider has deployed 6rd within a /27 that was granted recently for 6rd. A /24 was recently granted as well, likely for 6rd deployment. There are multiple providers in North America and around the world that have committed to delivering residential broadband service with 6rd, or are doing so today.
The following RIPE report shows the affect 6rd has had in France, which accounts for the largest deployment in all of Europe or North America.
http://labs.ripe.net/Members/emileaben/content-measuring-ipv6-web-clients-and-caching-resolvers-part-2-country-level-and-other-statistics
"In Figure 2 (Western Europe), we see a native IPv6 client capability in France of over 4%. This is mainly caused by free.fr that accounts for 70% of the native IPv6 clients measured. Note that technically free.fr uses 6rd-tunneling, but externally that looks, feels and smells like native IPv6"
9. Timetable for implementation:Immediate
More information about the ARIN-PPML
mailing list