<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.6003" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2>The 6rd proposal has been updated to satisfy ARIN
staff questions and input</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Changes made:<BR>1. relocated explanatory info into
the Rational<BR>2. Added justification guidelines to the Rational<BR>3. Removed
verbage that was unnessary and unfairly limiting to anyone wishing to use
6rd<BR>4. Included explanation for contiguous theory<BR>5. Added management of
IP space details<BR>6. Clarified the review and reclamation process</FONT></DIV>
<DIV><SPAN class=417004721-23092010><FONT face=Arial size=2>7. Added references
and research support</FONT></SPAN></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Revised version</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Template:
ARIN-POLICY-PROPOSAL-TEMPLATE-2.0</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> 1. Policy Proposal Name: IPv6 for 6rd
(RFC 5969)<BR> 2. Proposal
Originator<BR> <BR> <SPAN
class=417004721-23092010> </SPAN>1. name:Marla
Azinger<BR> 2.
email:marla.azinger@frontiercorp.com<BR>
3. telephone:585-413-9128<BR> 4.
organization:Frontier Communications<BR> <SPAN
class=417004721-23092010> </SPAN>1.
name:Mark Townsley<BR> 2.
email:townsley@cisco.com<BR> 3.
telephone:+33-1-5804-3483<BR> 4.
organization:Cisco Systems</FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><SPAN
class=417004721-23092010>
</SPAN>1. name:Alain Durand<BR>
2. email:adurand@juniper.net<BR>
3. telephone:215-908-4848<BR> 4.
organization:Juniper Networks</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2> 3. Proposal Version:1<BR>
4. Date:25 March 2010<BR> 5. Proposal type:NEW<BR> 6.
Policy term:permanent</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> 7. Policy statement:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>6rd is an incremental method for Service Providers
to deploy IPv6, defined in the IETF Standards Track RFC 5969.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>If you have IPv4 addresses then you automatically
qualify for IPv6 space for 6rd. Upon receipt of a 6rd request, an
appropriate additional IPv6 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>segregate address space requested under this policy
from regular IPv6 Allocation Supernets. From a management
perspective this address space is to be </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>treated as regular IPv6 address space.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>users separate from 6rd users to permit
optimization of aggregation. If an operator chooses to renumber users to an
address space outside the 6rd </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>aggregate when transitioning them to native IPv6,
the 6rd allocation may be returned to ARIN when it is no longer in use.<BR>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>organization transitions 6rd out of their
network.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>IPv6 network technology.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>8. Rationale:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>number of service providers to deploy IPv6 based on
automatic IPv6 prefix delegation and tunneling over existing IPv4
infrastructure. The chief </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>advantage of this approach is that it deploys the
service quickly while enabling the network administration to manage its
deployment outlays, and </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>ensures the correspondence between IPv4 and<BR>IPv6
routing. 6rd is distinct from other transition technologies such as<BR>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>designed to be transparent to both the user and the
rest of the Internet at large.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>To allow automatic prefix delegation to sites and
stateless tunneling, 6rd utilizes a mapping scheme between an operator's IPv6
allocation and<BR>IPv4 address space. With a /32 allocation and non-contiguous
IPv4 addressing plan, IPv6 deployment with 6rd is possible, but generally
results in no </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>likely if the operator has deployed IPv4 NAPT
technology within their network, and are addressing homes within a contiguous
block of RFC 1918 space </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>(e.g., 10/8).</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>realistic scenario of service providers in North
America deploying IPv6 with 6rd today:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> SP IPv6
prefix: 2001:0DB0::/28<BR>
v4suffix-length: 32 (unable to exclude common
bits<BR>
due to non-contiguous IPv4
allocations)<BR> 6rd CE router IPv4
address: 192.0.2.1<BR> 6rd site IPv6
prefix: 2001:0DBC:0000:2010::/60</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>network and addressed its subscribers with private
addresses accordingly:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> SP IPv6
prefix: 2001:0DB8::/32<BR> v4suffix-length:
24 (from 10/8, first octet (10) is
excluded<BR>
from the encoding)<BR> 6rd CE router IPv4
address: 10.100.100.1<BR> 6rd site IPv6
prefix: 2001:0DB8:6464:0100::/56</FONT></DIV>
<DIV> </DIV><FONT face=Arial size=2>
<DIV><BR>Justifications: Examples of how to display home networks using multiple
subnets is accomplished by providing a network plan that involves the use
of </DIV>
<DIV> </DIV>
<DIV>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 </DIV>
<DIV> </DIV>
<DIV>simply show how the end user environment is not a single LAN
subscriber.</DIV>
<DIV> </DIV>
<DIV>Supporting Research: 6rd is responsible for the largest production Ipv6
deployment today, supporting 4.5 million subscribers in France within a<BR>/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 </DIV>
<DIV> </DIV>
<DIV>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 </DIV>
<DIV> </DIV>
<DIV>North America and around the world that have committed to delivering
residential broadband service with 6rd, or are doing so today.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV><A
href="http://labs.ripe.net/Members/emileaben/content-measuring-ipv6-web-clients-and-caching-resolvers-part-2-country-level-and-other-statistics">http://labs.ripe.net/Members/emileaben/content-measuring-ipv6-web-clients-and-caching-resolvers-part-2-country-level-and-other-statistics</A></DIV>
<DIV> </DIV>
<DIV>"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 </DIV>
<DIV> </DIV>
<DIV>the native IPv6 clients measured. Note that technically free.fr uses
6rd-tunneling, but externally that looks, feels and smells like native
IPv6"</DIV>
<DIV> </DIV>
<DIV><BR> 9. Timetable for implementation:Immediate</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV></FONT> </DIV></BODY></HTML>