Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks

Network Working Group                                           T. Chown<br /> Request for Comments: 4554                     University of Southampton<br /> Category: Informational                                        June 2006<br /> <br /> <br />      Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks<br /> <br /> Status of This Memo<br /> <br />    This memo provides information for the Internet community.  It does<br />    not specify an Internet standard of any kind.  Distribution of this<br />    memo is unlimited.<br /> <br /> Copyright Notice<br /> <br />    Copyright (C) The Internet Society (2006).<br /> <br /> Abstract<br /> <br />    Ethernet VLANs are quite commonly used in enterprise networks for the<br />    purposes of traffic segregation.  This document describes how such<br />    VLANs can be readily used to deploy IPv6 networking in an enterprise,<br />    which focuses on the scenario of early deployment prior to<br />    availability of IPv6-capable switch-router equipment.  In this<br />    method, IPv6 may be routed in parallel with the existing IPv4 in the<br />    enterprise and delivered at Layer 2 via VLAN technology.  The IPv6<br />    connectivity to the enterprise may or may not enter the site via the<br />    same physical link.<br /> <br /> Table of Contents<br /> <br />    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />    2.  Enabling IPv6 per Link  . . . . . . . . . . . . . . . . . . . . 3<br />        2.1.  IPv6 Routing over VLANs . . . . . . . . . . . . . . . . . 3<br />        2.2.  One VLAN per Router Interface . . . . . . . . . . . . . . 4<br />        2.3.  Collapsed VLANs on a Single Interface . . . . . . . . . . 4<br />        2.4.  Congruent IPv4 and IPv6 Subnets . . . . . . . . . . . . . 5<br />        2.5.  IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . 5<br />        2.6.  Final IPv6 Deployment . . . . . . . . . . . . . . . . . . 5<br />    3.  Example VLAN Topology . . . . . . . . . . . . . . . . . . . . . 6<br />    4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7<br />    5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7<br />    6.  Informative References  . . . . . . . . . . . . . . . . . . . . 7<br />    Appendix A.  Configuration Example  . . . . . . . . . . . . . . . . 8<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Chown                        Informational                      [Page 1]<br /> <br /> RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006<br /> <br /> <br /> 1.  Introduction<br /> <br />    Ethernet VLANs are quite commonly used in enterprise networks for the<br />    purposes of traffic segregation.  This document describes how such<br />    VLANs can be readily used to deploy IPv6 networking in an enterprise,<br />    including the scenario of early deployment prior to availability of<br />    IPv6-capable switch-router equipment, where IPv6 may be routed in<br />    parallel with the existing IPv4 in the enterprise and delivered to<br />    the desired LANs via VLAN technology.<br /> <br />    It is expected that in the long run, sites migrating to dual-stack<br />    networking will either upgrade existing switch-router equipment to<br />    support IPv6 or procure new equipment that supports IPv6.  If a site<br />    already has production routers deployed that support IPv6, the<br />    procedures described in this document are not required.  In the<br />    interim, however, a method is required for early IPv6 adopters that<br />    enables IPv6 to be deployed in a structured, managed way to some or<br />    all of an enterprise network that currently lacks IPv6 support in its<br />    core infrastructure.<br /> <br />    The IEEE 802.1Q VLAN standard allows separate LANs to be deployed<br />    over a single bridged LAN, by inserting "Virtual LAN" tagging or<br />    membership information into Ethernet frames.  Hosts and switches that<br />    support VLANs effectively allow software-based reconfiguration of<br />    LANs through configuration of the tagging parameters.  The software<br />    control means that VLANs can be used to alter the LAN infrastructure<br />    without having to physically alter the wiring between the LAN<br />    segments and Layer 3 routers.<br /> <br />    Many IPv4 enterprise networks are utilising VLAN technology.  Where a<br />    site does not have IPv6-capable Layer 2/3 switch-router equipment,<br />    but VLANs are supported, a simple yet effective method exists to<br />    gradually introduce IPv6 to some or all of that site's network, in<br />    advance of the site's core infrastructure having dual-stack<br />    capability.<br /> <br />    If such a site wishes to introduce IPv6, it may do so by deploying a<br />    parallel IPv6 routing infrastructure (which is likely to be a<br />    different platform to the site's main infrastructure equipment, i.e.,<br />    one that supports IPv6 where the existing equipment does not), and<br />    then using VLAN technology to "overlay" IPv6 links onto existing IPv4<br />    links.  This can be achieved without needing any changes to the IPv4<br />    configuration.  The VLANs don't need to differentiate between IPv4<br />    and IPv6; the deployment is just dual-stack, as Ethernet is without<br />    VLANs.<br /> <br /> <br /> <br /> <br /> <br /> <br /> Chown                        Informational                      [Page 2]<br /> <br /> RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006<br /> <br /> <br />    The IPv4 default route to the VLAN is provided by one (IPv4) router,<br />    while the IPv6 default route to the VLAN is provided by a different<br />    (IPv6) router.  The IPv6 router can provide native IPv6 connectivity<br />    to the whole site with just a single physical interface, thanks to<br />    VLAN tagging and trunking, as described below.<br /> <br />    The IPv6 connectivity to the enterprise may or may not enter the site<br />    via the same physical link as the IPv4 traffic, and may be native or<br />    tunneled from the external provider to the IPv6 routing equipment.<br /> <br />    This VLAN usage is a solution adopted by a number of sites already,<br />    including that of the author.<br /> <br />    It should be noted that a parallel infrastructure will require<br />    additional infrastructure and thus cost, and will often require a<br />    separate link into the site (from an IPv6 provider), quite possibly<br />    tunneled, that will require the site's security policy to be applied<br />    (e.g., firewalling and intrusion detection).  For sites that believe<br />    early adoption of IPv6 is important, that price is one they may be<br />    quite willing to pay.  However, this document focuses on the<br />    technical issues of VLAN usage in such a scenario.<br /> <br /> 2.  Enabling IPv6 per Link<br /> <br />    The precise method by which IPv6 would be "injected" into the<br />    existing IPv4 network is deployment specific.  For example, perhaps a<br />    site has an IPv4-only router, connected to an Ethernet switch that<br />    supports VLANs and a number of hosts connected to that VLAN.  Let's<br />    further assume that the site has a dozen of these setups that it<br />    wishes to IPv6-enable immediately.  This could be done by upgrading<br />    the twelve routers to support IPv6, and turning IPv6 on those<br />    routers.  However, this may not be practical for various reasons.<br /> <br />    The simplest approach would be to connect an IPv6 router with one<br />    interface to an Ethernet switch, and connect that switch to other<br />    switches, and then use VLAN tags between the switches and the IPv6<br />    router to "reach" all the IPv4-only subnets from the IPv6 router.<br />    Thus, the general principle is that the IPv6 router device (e.g.,<br />    performing IPv6 Router Advertisements [1] in the case of stateless<br />    autoconfiguration) is connected to the target link through the use of<br />    VLAN-capable Layer 2 equipment.<br /> <br /> 2.1.  IPv6 Routing over VLANs<br /> <br />    In a typical scenario where connectivity is to be offered to a number<br />    of existing IPv6 internal subnets, one IPv6 router could be deployed,<br />    with both an external interface and one or more internal interfaces.<br />    The external interface connects to the wider IPv6 internet, and may<br /> <br /> <br /> <br /> Chown                        Informational                      [Page 3]<br /> <br /> RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006<br /> <br /> <br />    be dual-stack if some tunnel mechanism is used for external<br />    connectivity, or IPv6-only if a native external connection is<br />    available.<br /> <br />    The internal interface(s) can be connected directly to a VLAN-capable<br />    switch.  It is then possible to write VLAN tags on the packets sent<br />    from the internal router interface based on the target IPv6 link<br />    prefix.  The VLAN-tagged traffic is then transported across the<br />    internal VLAN-capable site infrastructure to the target IPv6 links<br />    (which may be dispersed widely across the site network).<br /> <br />    Where the IPv6 router is unable to VLAN-tag the packets, a protocol-<br />    based VLAN can be created on the VLAN-capable device connected to the<br />    IPv6 router, causing IPv6 traffic to be tagged and then redistributed<br />    on (congruent) IPv4 subnet links that lie in the same VLAN.<br /> <br /> 2.2.  One VLAN per Router Interface<br /> <br />    The VLAN marking may be done in different ways.  Some sites may<br />    prefer to use one router interface per VLAN; for example, if there<br />    are three internal IPv6 links, a standard PC-based IPv6 router with<br />    four Ethernet ports could be used, one for the external link and<br />    three for the internal links.  In such a case, one switch port would<br />    be needed per link, to receive the connectivity from each router<br />    port.<br /> <br />    In such a deployment, the IPv6 routing could be cascaded through<br />    lower-tier internal IPv6-only routers.  Here, the internal-facing<br />    ports on the IPv6 edge router may feed other IPv6 routers over IPv6-<br />    only links, which in turn inject the IPv6 connectivity (the stub<br />    links using 64-bit subnet prefixes and associated Router<br />    Advertisements) into the VLANs.<br /> <br /> 2.3.  Collapsed VLANs on a Single Interface<br /> <br />    Using multiple IPv6 routers and one port per IPv6 link (i.e., VLAN)<br />    may be unnecessary.  Many devices now support VLAN tagging based on<br />    virtual interfaces such that multiple IPv6 VLANs could be assigned<br />    (trunked) from one physical router interface port.  Thus, it is<br />    possible to use just one router interface for "aggregated" VLAN<br />    trunking from a switch.  This is a far more interesting case for a<br />    site planning the introduction of IPv6 to (part of) its site network.<br /> <br />    This approach is viable while the IPv6 traffic load is light.  As<br />    traffic volume grows, the single collapsed interface could be<br />    extended to utilise two or more physical ports, where the capacity of<br />    the IPv6 router device allows it.<br /> <br /> <br /> <br /> <br /> Chown                        Informational                      [Page 4]<br /> <br /> RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006<br /> <br /> <br /> 2.4.  Congruent IPv4 and IPv6 Subnets<br /> <br />    Such a VLAN-based technique can be used to deploy IPv6-only VLANs in<br />    an enterprise network.  However, most enterprises will be interested<br />    in dual-stack IPv4-IPv6 networking.<br /> <br />    In such a case, the IPv6 connectivity may be injected into the<br />    existing IPv4 VLANs, such that the IPv4 and IPv6 subnets are<br />    congruent (i.e., they coincide exactly when superimposed).  Such a<br />    method may have desirable administrative properties; for example, the<br />    devices in each IPv4 subnet will be in the same IPv6 subnets also.<br />    This is the method used at the author's site.<br /> <br />    Furthermore, IPv6-only devices may be gradually added into the subnet<br />    without any need to resize the IPv6 subnet (which may hold in effect<br />    an infinite number of hosts in a /64 in contrast to IPv4 where the<br />    subnet size is often relatively limited, or kept to a minimum<br />    possibly due to address space usage concerns).  The lack of<br />    requirement to periodically resize an IPv6 subnet is a useful<br />    administrative advantage for IPv6.<br /> <br /> 2.5.  IPv6 Addressing<br /> <br />    One site using this VLAN technique has chosen to number its IPv6<br />    links with the format [Site IPv6 prefix]:[VLAN ID]::/64.  The VLAN<br />    tag is 16 bits, so this can work with a typical maximum 48-bit site<br />    prefix.  Linking the VLAN ID into a site's addressing scheme may not<br />    fit topology and aggregation, and thus is not necessarily a<br />    recommended addressing plan, but some sites may wish to consider its<br />    usage.<br /> <br /> 2.6.  Final IPv6 Deployment<br /> <br />    The VLAN technique for IPv6 deployment offers a more structured<br />    alternative to opportunistic per-host intra-site tunnelling methods<br />    such as Intra-Site Automatic Tunnel Addressing Protocol ISATAP [2].<br />    It has the ability to offer a simple yet efficient method for early<br />    IPv6 deployment to an enterprise site.<br /> <br />    When the site acquires IPv6-capable switch-router equipment, the<br />    VLAN-based method can still be used for delivery of IPv6 links to<br />    physical switch interfaces, just as it is commonly used today for<br />    IPv4 subnets, but with a common routing infrastructure.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Chown                        Informational                      [Page 5]<br /> <br /> RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006<br /> <br /> <br /> 3.  Example VLAN Topology<br /> <br />    The following figure shows how a VLAN topology may be used to<br />    introduce IPv6 in an enterprise network, using a parallel IPv6<br />    routing infrastructure and VLAN tagging.<br /> <br />                        External IPv6 Internet<br />                                  |<br />                                  |<br />                         IPv6 Access Router<br />                                  |<br />                                  |<br />                    Switch-router with VLAN support<br />                                  |<br />                                  |<br />                   +--------------+----------------+<br />                   |Site enterprise infrastructure |<br />                   |   with support for VLANs      |<br />                   +----+--------------------+-----+<br />                        |                    |<br />                        |                    |<br />                  VLAN switch A         VLAN switch B<br />                    |        |               |<br />                    |        |               |<br />                Subnet1    Subnet2        Subnet3<br /> <br />          Figure 1: IPv6 deployment using VLANs (physical diagram)<br /> <br />    In this scenario, the IPv6 access router has one physical port facing<br />    toward the internal infrastructure.  In this example, it need only be<br />    IPv6-enabled, as its purpose is solely to handle IPv6 traffic for the<br />    enterprise.  The access router has an additional interface facing<br />    toward the external infrastructure, which in this example could be<br />    dual-stack if the external IPv6 connectivity is via a tunnel to an<br />    IPv6 ISP.<br /> <br />    A number of VLANs are handled by the internal-facing IPv6 router<br />    port; in this case, IPv6 links Subnet1, Subnet2, Subnet3.  The VLANs<br />    are seen as logical subinterfaces of the physical interface on the<br />    IPv6 access router, which is using the "collapsed VLAN" method<br />    described above, tagging the inbound traffic with one of three VLAN<br />    IDs depending on the target IPv6 Subnet prefix.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Chown                        Informational                      [Page 6]<br /> <br /> RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006<br /> <br /> <br />    The following figure shows how the IPv6 view of the deployment looks;<br />    all IPv6 subnets are on-link to the IPv6 access router, whether or<br />    not they share the same physical links over the VLAN infrastructure.<br /> <br />                      External IPv6 Internet<br />                                 |<br />                                 |<br />                      Site IPv6 Access Router<br />                        |        |         |<br />                        |        |         |<br />                     Subnet1  Subnet2   Subnet3<br /> <br />            Figure 2: IPv6 view of the deployment (logical view)<br /> <br />    In this example, the router acts as an IPv6 first-hop access router<br />    to the physical links, separately from the IPv4 first-hop router.<br />    This technique allows a site to easily "inject" native IPv6 into all<br />    the links where a VLAN-capable infrastructure is available, enabling<br />    partial or full IPv6 deployment on the wire in a site.<br /> <br /> 4.  Security Considerations<br /> <br />    There are no additional security considerations particular to this<br />    method of enabling IPv6 on a link.<br /> <br />    Where the IPv6 connectivity is delivered into the enterprise network<br />    by a different path from the IPv4 connectivity, care should be given<br />    that equivalent application of security policy (e.g., firewalling) is<br />    made to the IPv6 path.<br /> <br /> 5.  Acknowledgements<br /> <br />    The author would like to thank colleagues on the 6NET project, where<br />    this technique for IPv4-IPv6 coexistence is widely deployed, in<br />    particular Pekka Savola (CSC/FUNET), but also including Janos Mohacsi<br />    (Hungarnet), Martin Dunmore and Chris Edwards (Lancaster University),<br />    Christian Strauf (JOIN Project, University of Muenster), and Stig<br />    Venaas (UNINETT).<br /> <br /> 6.  Informative References<br /> <br />    [1]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery<br />         for IP Version 6 (IPv6)", RFC 2461, December 1998.<br /> <br />    [2]  Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site<br />         Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214,<br />         October 2005.<br /> <br /> <br /> <br /> <br /> Chown                        Informational                      [Page 7]<br /> <br /> RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006<br /> <br /> <br /> Appendix A.  Configuration Example<br /> <br />    This section describes a configuration example for using a computer<br />    running the FreeBSD variant of the Berkeley Software Distribution<br />    (BSD) operating system as a router to deploy IPv6 networking across a<br />    number of IPv6 links on an enterprise (in this case, six links), for<br />    a scenario similar to the one described above.  Here, the precise<br />    configuration may of course vary depending on the existing site VLAN<br />    deployment.  This section highlights that the VLAN configuration must<br />    be manually configured; the support is not "automatic".<br /> <br />    In this example, the configuration is for an IPv6 BSD router<br />    connected directly to a site's external IPv6 access router.  The BSD<br />    router has one interface (dc0) toward the site IPv6 access router,<br />    and three interfaces (dc1, dc2, dc3) over which the internal routing<br />    is performed (the number of interfaces can be varied; three are used<br />    here to distribute the traffic load).  The IPv6 documentation prefix<br />    (2001:db8::/32) is used in the example.<br /> <br /> --- Example IPv6 VLAN configuration, FreeBSD ---<br /> <br /> #<br /> # To IPv6 enable a vlan<br /> #<br /> # 1. Add a new vlan device to cloned_interfaces called vlanX<br /> #<br /> # 2. Add an ifconfig_vlanX line, the number is the vlan tag ID<br /> #<br /> # 3. Add vlanX to ipv6_network_interfaces<br /> #<br /> # 4. Add an ipv6_ifconfig_vlanX line, with a new unique prefix<br /> #<br /> # 5. Add vlanX to rtadvd_interface<br /> #<br /> # 6. Add vlanX to ipv6_router_flags<br /> <br /> ### Interfaces ###<br /> <br /> # Bring physical interfaces up<br /> ifconfig_dc0="up"<br /> ifconfig_dc1="up"<br /> ifconfig_dc2="up"<br /> ifconfig_dc3="up"<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Chown                        Informational                      [Page 8]<br /> <br /> RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006<br /> <br /> <br /> # Create VLan interfaces<br /> cloned_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6"<br /> <br /> # Upstream link to IPv6 Access Router<br /> ifconfig_vlan0="vlan 37 vlandev dc0"<br /> <br /> # Downstream interfaces, load balance over interfaces dc1,dc2,dc3<br /> ifconfig_vlan1="vlan 11 vlandev dc1" # Subnet1<br /> ifconfig_vlan2="vlan 17 vlandev dc2" # Subnet2<br /> ifconfig_vlan3="vlan 24 vlandev dc3" # Subnet3<br /> ifconfig_vlan4="vlan 25 vlandev dc1" # Subnet4<br /> ifconfig_vlan5="vlan 34 vlandev dc2" # Subnet5<br /> ifconfig_vlan6="vlan 14 vlandev dc3" # Subnet6<br /> <br /> ### IPv6 ###<br /> <br /> # Enable ipv6<br /> ipv6_enable="YES"<br /> <br /> # Forwarding<br /> ipv6_gateway_enable="YES"<br /> <br /> # Define Interfaces<br /> ipv6_network_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6"<br /> # Define addresses<br /> ipv6_ifconfig_vlan0="2001:db8:d0:101::2 prefixlen 64" # Uplink<br /> ipv6_ifconfig_vlan1="2001:db8:d0:111::1 prefixlen 64" # Subnet1<br /> ipv6_ifconfig_vlan2="2001:db8:d0:112::1 prefixlen 64" # Subnet2<br /> ipv6_ifconfig_vlan3="2001:db8:d0:121::1 prefixlen 64" # Subnet3<br /> ipv6_ifconfig_vlan4="2001:db8:d0:113::1 prefixlen 64" # Subnet4<br /> ipv6_ifconfig_vlan5="2001:db8:d0:114::1 prefixlen 64" # Subnet5<br /> ipv6_ifconfig_vlan6="2001:db8:d0:115::1 prefixlen 64" # Subnet6<br /> <br /> # Router advertisements<br /> rtadvd_enable="YES"<br /> rtadvd_interfaces="-s vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6"<br /> <br /> ### Routing ###<br /> <br /> # Multicast<br /> mroute6d_enable="YES"<br /> mroute6d_program="/sbin/pim6sd"<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Chown                        Informational                      [Page 9]<br /> <br /> RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006<br /> <br /> <br /> # RIP-ng<br /> ipv6_router_enable="YES"<br /> ipv6_router_flags="-N dc0,dc1,dc2,dc3, vlan1,vlan2,vlan3,<br />                    vlan4,vlan5,vlan6"<br /> <br /> --- End of configuration ---<br /> <br />    Note that if there was only one internal-facing interface, then again<br />    so long as the OS supported VLAN trunking, all the VLAN IDs could be<br />    associated to that interface (dc1, for example).<br /> <br />    The VLAN IDs need to be managed by the site administrator, but would<br />    probably already be assigned for existing IPv4 subnets (ones into<br />    which IPv6 is being introduced).<br /> <br />    For a large enterprise, a combination of internal tunnels and VLAN<br />    usage could be used; the whole site need not be enabled by VLAN<br />    tagging alone.  This choice is one for the site administrator to<br />    make.<br /> <br /> Author's Address<br /> <br />    Tim Chown<br />    University of Southampton<br />    Southampton, Hampshire  SO17 1BJ<br />    United Kingdom<br /> <br />    EMail: tjc@ecs.soton.ac.uk<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Chown                        Informational                     [Page 10]<br /> <br /> RFC 4554            VLANs for IPv4-IPv6 Coexistence            June 2006<br /> <br /> <br /> Full Copyright Statement<br /> <br />    Copyright (C) The Internet Society (2006).<br /> <br />    This document is subject to the rights, licenses and restrictions<br />    contained in BCP 78, and except as set forth therein, the authors<br />    retain all their rights.<br /> <br />    This document and the information contained herein are provided on an<br />    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS<br />    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET<br />    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,<br />    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE<br />    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED<br />    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.<br /> <br /> Intellectual Property<br /> <br />    The IETF takes no position regarding the validity or scope of any<br />    Intellectual Property Rights or other rights that might be claimed to<br />    pertain to the implementation or use of the technology described in<br />    this document or the extent to which any license under such rights<br />    might or might not be available; nor does it represent that it has<br />    made any independent effort to identify any such rights.  Information<br />    on the procedures with respect to rights in RFC documents can be<br />    found in BCP 78 and BCP 79.<br /> <br />    Copies of IPR disclosures made to the IETF Secretariat and any<br />    assurances of licenses to be made available, or the result of an<br />    attempt made to obtain a general license or permission for the use of<br />    such proprietary rights by implementers or users of this<br />    specification can be obtained from the IETF on-line IPR repository at<br />    http://www.ietf.org/ipr.<br /> <br />    The IETF invites any interested party to bring to its attention any<br />    copyrights, patents or patent applications, or other proprietary<br />    rights that may cover technology that may be required to implement<br />    this standard.  Please address the information to the IETF at<br />    ietf-ipr@ietf.org.<br /> <br /> Acknowledgement<br /> <br />    Funding for the RFC Editor function is provided by the IETF<br />    Administrative Support Activity (IASA).<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Chown                        Informational                     [Page 11]

Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks

Network Working Group                                           T. Chown Request for Comments: 4554                     University of South...

Read more »

IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Protocol Specification

<pre> Internet Engineering Task Force (IETF) W. Townsley Request for Comments: 5969 O. Troan Category: Standards Track Cisco ISSN: 2070-1721 August 2010 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification Abstract This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5969. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Townsley & Troan Standards Track [Page 1] RFC 5969 6rd August 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. 6rd Prefix Delegation . . . . . . . . . . . . . . . . . . . . 5 5. Troubleshooting and Traceability . . . . . . . . . . . . . . . 7 6. Address Selection . . . . . . . . . . . . . . . . . . . . . . 7 7. 6rd Configuration . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Customer Edge Configuration . . . . . . . . . . . . . . . 8 7.1.1. 6rd DHCPv4 Option . . . . . . . . . . . . . . . . . . 9 7.2. Border Relay Configuration . . . . . . . . . . . . . . . . 10 8. Neighbor Unreachability Detection . . . . . . . . . . . . . . 11 9. IPv6 in IPv4 Encapsulation . . . . . . . . . . . . . . . . . . 12 9.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . 13 9.2. Receiving Rules . . . . . . . . . . . . . . . . . . . . . 13 10. Transition Considerations . . . . . . . . . . . . . . . . . . 14 11. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 15.1. Normative References . . . . . . . . . . . . . . . . . . . 16 15.2. Informative References . . . . . . . . . . . . . . . . . . 17 1. Introduction The original idea and the name of the mechanism (6rd) described in [RFC5569] details a successful commercial "rapid deployment" of the 6rd mechanism by a residential service provider and is recommended reading. This document describes the 6rd mechanism, which has been extended for use in more general environments. Throughout this document, the term 6to4 is used to refer to the mechanism described in [RFC3056] and 6rd is the mechanism defined herein. 6rd specifies a protocol mechanism to deploy IPv6 to sites via a service provider's (SP's) IPv4 network. It builds on 6to4 [RFC3056], with the key differentiator that it utilizes an SP's own IPv6 address prefix rather than a well-known prefix (2002::/16). By using the SP's IPv6 prefix, the operational domain of 6rd is limited to the SP network and is under its direct control. From the perspective of customer sites and the IPv6 Internet at large, the IPv6 service provided is equivalent to native IPv6. The 6rd mechanism relies upon an algorithmic mapping between the IPv6 and IPv4 addresses that are assigned for use within the SP network. This mapping allows for automatic determination of IPv4 tunnel endpoints from IPv6 prefixes, allowing stateless operation of 6rd. Townsley & Troan Standards Track [Page 2] RFC 5969 6rd August 2010 6rd views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) [RFC2491] model. A 6rd domain consists of 6rd Customer Edge (CE) routers and one or more 6rd Border Relays (BRs). IPv6 packets encapsulated by 6rd follow the IPv4 routing topology within the SP network among CEs and BRs. 6rd BRs are traversed only for IPv6 packets that are destined to or are arriving from outside the SP's 6rd domain. As 6rd is stateless, BRs may be reached using anycast for failover and resiliency (in a similar fashion to [RFC3068]). On the "customer-facing" (i.e., "LAN") side of a CE, IPv6 is implemented as it would be for any native IP service delivered by the SP, and further considerations for IPv6 operation on the LAN side of the CE is out of scope for this document. On the "SP-facing" (i.e., "WAN") side of the 6rd CE, the WAN interface itself, encapsulation over Ethernet, ATM or PPP, as well as control protocols such as PPPoE, IPCP, DHCP, etc. all remain unchanged from current IPv4 operation. Although 6rd was designed primarily to support IPv6 deployment to a customer site (such as a residential home network) by an SP, it can equally be applied to an individual IPv6 host acting as a CE. 6rd relies on IPv4 and is designed to deliver production-quality IPv6 alongside IPv4 with as little change to IPv4 networking and operations as possible. Native IPv6 deployment within the SP network itself may continue for the SP's own purposes while delivering IPv6 service to sites supported by 6rd. Once the SP network and operations can support fully native IPv6 access and transport, 6rd may be discontinued. 6rd utilizes the same encapsulation and base mechanism as 6to4 and could be viewed as a superset of 6to4 (6to4 could be achieved by setting the 6rd prefix to 2002::/16). Unlike 6to4, 6rd is for use only in an environment where a service provider closely manages the delivery of IPv6 service. 6to4 routes with the 2002::/16 prefix may exist alongside 6rd in the 6rd CE router, and doing so may offer some efficiencies when communicating directly with 6to4 routers. The 6rd link model can be extended to support IPv6 multicast. IPv6 multicast support is left for future consideration. How this mechanism should be used and other deployment and operational considerations are considered out of scope for this document. Townsley & Troan Standards Track [Page 3] RFC 5969 6rd August 2010 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Terminology 6rd prefix An IPv6 prefix selected by the service provider for use by a 6rd domain. There is exactly one 6rd prefix for a given 6rd domain. An SP may deploy 6rd with a single 6rd domain or multiple 6rd domains. 6rd Customer Edge (6rd CE) A device functioning as a Customer Edge router in a 6rd deployment. In a residential broadband deployment, this type of device is sometimes referred to as a "Residential Gateway" (RG) or "Customer Premises Equipment" (CPE). A typical 6rd CE serving a residential site has one WAN side interface, one or more LAN side interfaces, and a 6rd virtual interface. A 6rd CE may also be referred to simply as a "CE" within the context of 6rd. 6rd delegated prefix The IPv6 prefix calculated by the CE for use within the customer site by combining the 6rd prefix and the CE IPv4 address obtained via IPv4 configuration methods. This prefix can be considered logically equivalent to a DHCPv6 IPv6 delegated prefix [RFC3633]. 6rd domain A set of 6rd CEs and BRs connected to the same virtual 6rd link. A service provider may deploy 6rd with a single 6rd domain, or may utilize multiple 6rd domains. Each domain requires a separate 6rd prefix. CE LAN side The functionality of a 6rd CE that serves the "Local Area Network (LAN)" or "customer-facing" side of the CE. The CE LAN side interface is fully IPv6 enabled. Townsley & Troan Standards Track [Page 4] RFC 5969 6rd August 2010 CE WAN side The functionality of a 6rd CE that serves the "Wide Area Network (WAN)" or "Service Provider- facing" side of the CE. The CE WAN side is IPv4-only. 6rd Border Relay (BR) A 6rd-enabled router managed by the service provider at the edge of a 6rd domain. A Border Relay router has at least one of each of the following: an IPv4-enabled interface, a 6rd virtual interface acting as an endpoint for the 6rd IPv6 in IPv4 tunnel, and an IPv6 interface connected to the native IPv6 network. A 6rd BR may also be referred to simply as a "BR" within the context of 6rd. BR IPv4 address The IPv4 address of the 6rd Border Relay for a given 6rd domain. This IPv4 address is used by the CE to send packets to a BR in order to reach IPv6 destinations outside of the 6rd domain. 6rd virtual interface Internal multi-point tunnel interface where 6rd encapsulation and decapsulation of IPv6 packets inside IPv4 occurs. A typical CE or BR implementation requires only one 6rd virtual interface. A BR operating in multiple 6rd domains may require more than one 6rd virtual interface, but no more than one per 6rd domain. CE IPv4 address The IPv4 address given to the CE as part of normal IPv4 Internet access (i.e., configured via DHCP, PPP, or otherwise). This address may be global or private [RFC1918] within the 6rd domain. This address is used by a 6rd CE to create the 6rd delegated prefix as well as to send and receive IPv4-encapsulated IPv6 packets. 4. 6rd Prefix Delegation The 6rd delegated prefix for use at a customer site is created by combining the 6rd prefix and all or part of the CE IPv4 address. From these elements, the 6rd delegated prefix is automatically created by the CE for the customer site when IPv4 service is obtained. This 6rd delegated prefix is used in the same manner as a prefix obtained via DHCPv6 prefix delegation [RFC3633]. Townsley & Troan Standards Track [Page 5] RFC 5969 6rd August 2010 In 6to4, a similar operation is performed by incorporating an entire IPv4 address at a fixed location following a well-known /16 IPv6 prefix. In 6rd, the IPv6 prefix as well as the position and number of bits of the IPv4 address incorporated varies from one 6rd domain to the next. 6rd allows the SP to adjust the size of the 6rd prefix, how many bits are used by the 6rd mechanism, and how many bits are left to be delegated to customer sites. To allow for stateless address auto-configuration on the CE LAN side, a 6rd delegated prefix SHOULD be /64 or shorter. The 6rd delegated prefix is created by concatenating the 6rd prefix and a consecutive set of bits from the CE IPv4 address in order. The length of the 6rd delegated prefix is equal to length of the 6rd prefix (n) plus the number of bits from the CE IPv4 address (o). The figure shows the format of an IPv6 address (Section 2.5.4 of [RFC4291]) with a 6rd prefix and an embedded CE IPv4 address: | n bits | o bits | m bits | 128-n-o-m bits | +---------------+--------------+-----------+------------------------+ | 6rd prefix | IPv4 address | subnet ID | interface ID | +---------------+--------------+-----------+------------------------+ |<--- 6rd delegated prefix --->| Figure 1 For example, if the 6rd prefix is /32 and 24 bits of the CE IPv4 address is used (e.g., all CE IPv4 addresses can be aggregated by a 10.0.0.0/8), then the size of the 6rd delegated prefix for each CE is automatically calculated to be /56 (32 + 24 = 56). Embedding less than the full 32 bits of a CE IPv4 address is possible only when an aggregated block of IPv4 addresses is available for a given 6rd domain. This may not be practical with global IPv4 addresses, but is quite likely in a deployment where private addresses are being assigned to CEs. If private addresses overlap within a given 6rd deployment, the deployment may be divided into separate 6rd domains, likely along the same topology lines the NAT- based IPv4 deployment itself would require. In this case, each domain is addressed with a different 6rd prefix. Each 6rd domain may use a different encoding of the embedded IPv4 address, even within the same service provider. For example, if multiple IPv4 address blocks with different levels of aggregation are used at the same service provider, the number of IPv4 bits needed to encode the 6rd delegated prefix may vary between each block. In this case, different 6rd prefixes, and hence separate 6rd domains, may be used to support the different encodings. Townsley & Troan Standards Track [Page 6] RFC 5969 6rd August 2010 Since 6rd delegated prefixes are selected algorithmically from an IPv4 address, changing the IPv4 address will cause a change in the IPv6 delegated prefix which would ripple through the site's network and could be disruptive. As such, it is recommended that the service provider assign CE IPv4 addresses with relatively long lifetimes. 6rd IPv6 address assignment, and hence the IPv6 service itself, is tied to the IPv4 address lease; thus, the 6rd service is also tied to this in terms of authorization, accounting, etc. For example, the 6rd delegated prefix has the same lifetime as its associated IPv4 address. The prefix lifetimes advertised in Router Advertisements or used by DHCP on the CE LAN side MUST be equal to or shorter than the IPv4 address lease time. If the IPv4 lease time is not known, the lifetime of the 6rd delegated prefix SHOULD follow the defaults specified in [RFC4861]. 5. Troubleshooting and Traceability A 6rd IPv6 address and associated IPv4 address for a given customer can always be determined algorithmically by the service provider that operates the given 6rd domain. This may be useful for referencing logs and other data at a service provider that may have more robust operational tools for IPv4 than IPv6. This also allows IPv4 data path, node, and endpoint monitoring to be applicable to IPv6. The 6rd CE and BR SHOULD support the IPv6 Subnet-Router anycast address [RFC4291] for its own 6rd delegated prefix. This allows, for example, IPv6 ICMP echo messages to be sent to the 6rd virtual interface itself for additional troubleshooting of the internal operation of 6rd at a given CE or BR. In the case of the BR, the IPv4 address used to calculate the 6rd delegated prefix is the configured BR IPv4 address. 6. Address Selection All addresses assigned from 6rd delegated prefixes should be treated as native IPv6. No changes to the source address selection or destination address selection policy table [RFC3484] are necessary. 7. 6rd Configuration For a given 6rd domain, the BR and CE MUST be configured with the following four 6rd elements. The configured values for these four 6rd elements are identical for all CEs and BRs within a given 6rd domain. Townsley & Troan Standards Track [Page 7] RFC 5969 6rd August 2010 IPv4MaskLen The number of high-order bits that are identical across all CE IPv4 addresses within a given 6rd domain. For example, if there are no identical bits, IPv4MaskLen is 0 and the entire CE IPv4 address is used to create the 6rd delegated prefix. If there are 8 identical bits (e.g., the Private IPv4 address range 10.0.0.0/8 is being used), IPv4MaskLen is equal to 8 and IPv4MaskLen high-order bits are stripped from the IPv4 address before constructing the corresponding 6rd delegated prefix. 6rdPrefix The 6rd IPv6 prefix for the given 6rd domain. 6rdPrefixLen The length of the 6rd IPv6 prefix for the given 6rd domain. 6rdBRIPv4Address The IPv4 address of the 6rd Border Relay for a given 6rd domain. 7.1. Customer Edge Configuration The four 6rd elements are set to values that are the same across all CEs within a 6rd domain. The values may be configured in a variety of manners, including provisioning methods such as the Broadband Forum's "TR-69" [TR069] Residential Gateway management interface, an XML-based object retrieved after IPv4 connectivity is established, a DNS record, an SMIv2 MIB [RFC2578], PPP IPCP, or manual configuration by an administrator. This document describes how to configure the necessary parameters via a single DHCP option. A CE that allows IPv4 configuration by DHCP SHOULD implement this option. Other configuration and management methods may use the format described by this option for consistency and convenience of implementation on CEs that support multiple configuration methods. The only remaining provisioning information the CE requires in order to calculate the 6rd delegated prefix and enable IPv6 connectivity is an IPv4 address for the CE. This CE IPv4 address is configured as part of obtaining IPv4 Internet access (i.e., configured via DHCP, PPP, or otherwise). This address may be global or private [RFC1918] within the 6rd domain. A single 6rd CE MAY be connected to more than one 6rd domain, just as any router may have more than one IPv6-enabled service provider facing interface and more than one set of associated delegated prefixes assigned by DHCPv6 prefix delegation or other means. Each Townsley & Troan Standards Track [Page 8] RFC 5969 6rd August 2010 domain a given CE operates within would require its own set of 6rd configuration elements and would generate its own 6rd delegated prefix. 7.1.1. 6rd DHCPv4 Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_6RD | option-length | IPv4MaskLen | 6rdPrefixLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 6rdPrefix | | (16 octets) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6rdBRIPv4Address(es) | . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 option-code OPTION_6RD (212) option-length The length of the DHCP option in octets (22 octets with one BR IPv4 address). IPv4MaskLen The number of high-order bits that are identical across all CE IPv4 addresses within a given 6rd domain. This may be any value between 0 and 32. Any value greater than 32 is invalid. 6rdPrefixLen The IPv6 prefix length of the SP's 6rd IPv6 prefix in number of bits. For the purpose of bounds checking by DHCP option processing, the sum of (32 - IPv4MaskLen) + 6rdPrefixLen MUST be less than or equal to 128. 6rdBRIPv4Address One or more IPv4 addresses of the 6rd Border Relay(s) for a given 6rd domain. Townsley & Troan Standards Track [Page 9] RFC 5969 6rd August 2010 6rdPrefix The service provider's 6rd IPv6 prefix represented as a 16-octet IPv6 address. The bits in the prefix after the 6rdPrefixlen number of bits are reserved and MUST be initialized to zero by the sender and ignored by the receiver. The CE MUST include a Parameter Request List Option [RFC2132] for the OPTION_6RD. Because the OPTION_6RD contains one IPv4MaskLen/ 6rdPrefixLen/6rdPrefix block, and because DHCP cannot convey more than one instance of an option, OPTION_6RD is limited to provision at most a single 6rd domain. Provisioning of a CE router connected to multiple 6rd domains is outside the scope of this protocol specification. The presence of the OPTION_6RD DHCP option is an indication of the availability of the 6rd service. By default, receipt of a valid 6rd DHCP option by a 6rd-capable CE results in configuration of the 6rd virtual interface and associated delegated prefix for use on the CE's LAN side. The CE MUST be able to configure the 6rd mechanism to be disabled, in which case the 6rd DHCP option, if received, is silently ignored. A detailed description of CE behavior using multiple BR IPv4 addresses is left for future consideration. In such a case, a CE MUST support at least one BR IPv4 address and MAY support more than one. When 6rd is enabled, a typical CE router will install a default route to the BR, a black hole route for the 6rd delegated prefix, and routes for any LAN side assigned and advertised prefixes. For example, using a CE IPv4 address of 10.100.100.1, a BR IPv4 address of 10.0.0.1, an IPv4MaskLen of 8, 2001:db8::/32 as the 6rdPrefix, and one /64 prefix assigned to a LAN side interface, a typical CE routing table will look like: ::/0 -> 6rd-virtual-int0 via 2001:db8:0:100:: (default route) 2001:db8::/32 -> 6rd-virtual-int0 (direct connect to 6rd) 2001:db8:6464:100::/56 -> Null0 (delegated prefix null route) 2001:db8:6464:100::/64 -> Ethernet0 (LAN interface) 7.2. Border Relay Configuration The 6rd BR MUST be configured with the same 6rd elements as the 6rd CEs operating within the same domain. For increased reliability and load balancing, the BR IPv4 address may be an anycast address shared across a given 6rd domain. As 6rd is stateless, any BR may be used at any time. If the BR IPv4 address is Townsley & Troan Standards Track [Page 10] RFC 5969 6rd August 2010 anycast the relay MUST use this anycast IPv4 address as the source address in packets relayed to CEs. Since 6rd uses provider address space, no specific routes need to be advertised externally for 6rd to operate, neither in IPv6 nor IPv4 BGP. However, if anycast is used for the 6rd IPv4 relays, the anycast addresses must be advertised in the service provider's IGP. 8. Neighbor Unreachability Detection Neighbor Unreachability Detection (NUD) for tunnels is described in Section 3.8 of [RFC4213]. In 6rd, all CEs and BRs can be considered as connected to the same virtual link and therefore neighbors to each other. This section describes how to utilize neighbor unreachability detection without negatively impacting the scalability of a 6rd deployment. A typical 6rd deployment may consist of a very large number of CEs within the same domain. Reachability between CEs is based on IPv4 routing, and sending NUD or any periodic packets between 6rd CE devices beyond isolated troubleshooting of the 6rd mechanism is NOT RECOMMENDED. While reachability detection between a given 6rd CE and BR is not necessary for the proper operation of 6rd, in cases where a CE has alternate paths for BR reachability to choose from, it could be useful. Sending NUD messages to a BR, in particular periodic messages from a very large number of CEs, could result in overloading of the BR control message processing path, negatively affecting scalability of the 6rd deployment. Instead, a CE that needs to determine BR reachability MUST utilize a method that allows reachability detection packets to follow a typical data forwarding path without special processing by the BR. One such method is described below. 1. The CE constructs a payload of any size and content to be sent to the BR (e.g., a zero-length null payload, a padded payload designed to test a certain MTU, a NUD message, etc.). The exact format of the message payload is not important as the BR will not be processing it directly. 2. The desired payload is encapsulated with the inner IPv6 and outer IPv4 headers as follows: * The IPv6 destination address is set to an address from the CE's 6rd delegated prefix that is assigned to a virtual interface on the CE. Townsley & Troan Standards Track [Page 11] RFC 5969 6rd August 2010 * The IPv6 source address is set to an address from the CE's 6rd delegated prefix as well, including the same as used for the IPv6 destination address. * The IPv4 header is then added as it normally would be for any packet destined for the BR. That is, the IPv4 destination address is that of the BR, and the source address is the CE IPv4 address. 3. The CE sends the constructed packet out the interface on which BR reachability is being monitored. On successful receipt at the BR, the BR MUST decapsulate and forward the packet normally. That is, the IPv4 header is decapsulated normally, revealing the IPv6 destination as the CE, which in turn results in the packet being forwarded to that CE via the 6rd mechanism (i.e., the IPv4 destination is that of the CE that originated the packet, and the IPv4 source is that of the BR). 4. Arrival of the constructed IPv6 packet at the CE's IPv6 address completes one round trip to and from the BR, without causing the BR to process the message outside of its normal data forwarding path. The CE then processes the IPv6 packet accordingly (updating keepalive timers, metrics, etc.). The payload may be empty or could contain values that are meaningful to the CE. Sending a proper NUD message could be convenient for some implementations (note that the BR will decrement the IPv6 hop limit). Since the BR forwards the packet as any other data packet without any processing of the payload itself, the format of the payload is left as a choice to the implementer. 9. IPv6 in IPv4 Encapsulation IPv6 in IPv4 encapsulation and forwarding manipulations (e.g., handling packet markings, checksumming, etc.) is performed as specified in Section 3.5 of "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213], which is the same mechanism used by 6to4 [RFC3056]. ICMPv4 errors are handled as specified in Section 3.4 of [RFC4213]. By default, the IPv6 Traffic Class field MUST be copied to the IPv4 ToS (Type of Service) field. This default behavior MAY be overridden by configuration. See [RFC2983] and [RFC3168] for further information related to IP Differentiated Services and tunneling. IPv6 packets from a CE are encapsulated in IPv4 packets when they leave the site via its CE WAN side interface. The CE IPv4 address MUST be configured to send and receive packets on this interface. Townsley & Troan Standards Track [Page 12] RFC 5969 6rd August 2010 The 6rd link is modeled as an NBMA link similar to other automatic IPv6 in IPv4 tunneling mechanisms like [RFC5214], with all 6rd CEs and BRs defined as off-link neighbors from one other. The link-local address of a 6rd virtual interface performing the 6rd encapsulation would, if needed, be formed as described in Section 3.7 of [RFC4213]. However, no communication using link-local addresses will occur. 9.1. Maximum Transmission Unit Maximum transmission unit (MTU) and fragmentation issues for IPv6 in IPv4 tunneling are discussed in detail in Section 3.2 of RFC 4213 [RFC4213]. 6rd's scope is limited to a service provider network. IPv4 Path MTU discovery MAY be used to adjust the MTU of the tunnel as described in Section 3.2.2 of RFC 4213 [RFC4213], or the 6rd Tunnel MTU might be explicitly configured. The use of an anycast source address could lead to any ICMP error message generated on the path being sent to a different BR. Therefore, using dynamic tunnel MTU Section 3.2.2 of [RFC4213] is subject to IPv4 Path MTU blackholes. Multiple BRs using the same anycast source address could send fragmented packets to the same IPv6 CE at the same time. If the fragmented packets from different BRs happen to use the same fragment ID, incorrect reassembly might occur. For this reason, a BR using an anycast source address MUST set the IPv4 Don't Fragment flag. If the MTU is well-managed such that the IPv4 MTU on the CE WAN side interface is set so that no fragmentation occurs within the boundary of the SP, then the 6rd Tunnel MTU should be set to the known IPv4 MTU minus the size of the encapsulating IPv4 header (20 bytes). For example, if the IPv4 MTU is known to be 1500 bytes, the 6rd Tunnel MTU might be set to 1480 bytes. Absent more specific information, the 6rd Tunnel MTU SHOULD default to 1280 bytes. 9.2. Receiving Rules In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE MUST validate the embedded IPv4 source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the configured parameters of the 6rd domain. If the two source addresses do not match, the packet MUST be dropped and a counter incremented to indicate that a potential spoofing attack may be underway. Additionally, a CE MUST allow forwarding of packets sourced by the configured BR IPv4 address. Townsley & Troan Standards Track [Page 13] RFC 5969 6rd August 2010 By default, the CE router MUST drop packets received on the 6rd virtual interface (i.e., after decapsulation of IPv4) for IPv6 destinations not within its own 6rd delegated prefix. 10. Transition Considerations An SP network can migrate to IPv6 at its own pace with little or no effect on customers being provided IPv6 via 6rd. When native IPv6 connectivity is available, an administrator can choose to disable 6rd. The SP can choose to provision a separate IPv6 address block for native service, or reuse the 6rd prefix block itself. If the SP uses a separate address block, moving from 6rd to native IPv6 is seen as a normal IPv6 renumbering event for the customer. Renumbering may also be avoided by injecting the 6rd delegated prefix into the SP's IPv6 routing domain. Further considerations with regards to transitioning from 6rd to native IPv6 are not covered in this protocol specification. 11. IPv6 Address Space Usage As 6rd uses service-provider address space, 6rd uses the normal address delegation a service provider gets from its Regional Internet Registry (RIR) and no global allocation of a single 6rd IANA-assigned address block like the 6to4 2002::/16 is needed. The service provider's prefix must be short enough to encode the unique bits of all IPv4 addresses within a given 6rd domain and still provide enough IPv6 address space to the residential site. Assuming a worst case scenario using the full 32 bits for the IPv4 address, assigning a /56 for customer sites would mean that each service provider using 6rd would require a /24 for 6rd in addition to other IPv6 addressing needs. Assuming that 6rd would be stunningly successful and taken up by almost all Autonomous System (AS) number holders (32K today), then the total address usage of 6rd would be equivalent to a /9. If the SP instead delegated /60s to sites, the service provider would require a /28, and the total global address consumption by 6rd would be equivalent to a /13. Again, this assumes that 6rd is used by all AS number holders in the IPv4 Internet today at the same time, that none have used any of 6rd's address compression techniques, and that none have moved to native IPv6 and reclaimed the 6rd space that was being used for other purposes. To alleviate concerns about address usage, 6rd allows for leaving out redundant IPv4 prefix bits in the encoding of the IPv4 address inside the 6rd IPv6 address. This is most useful where the IPv4 address space is very well aggregated. For example, to provide each customer Townsley & Troan Standards Track [Page 14] RFC 5969 6rd August 2010 with a /60, if a service provider has all its IPv4 customers under a /12 then only 20 bits needs to be used to encode the IPv4 address and the service provider would only need a /40 IPv6 allocation for 6rd. If private address space is used, then a 10/8 would require a /36. If multiple 10/8 domains are used, then up to 16 could be supported within a /32. If a service provider has a non-aggregatable IPv4 space and requiring the use of the full 32-bit IPv4 address in the encoding of the 6rd IPv6 address, the 6rd prefix MUST be no longer than /32 in order to offer a 6rd delegated prefix of at least /64. The 6rd address block can be reclaimed when all users of it have transitioned to native IPv6 service. This may require renumbering of customer sites and use of additional address space during the transition period. 12. Security Considerations A 6to4 relay router as specified in [RFC3056] can be used as an open relay. It can be used to relay IPv6 traffic and as a traffic anonymizer. By restricting the 6rd domain to within a provider network, a CE only needs to accept packets from a single or small set of known 6rd BR IPv4 addresses. As such, many of the threats against 6to4 as described in [RFC3964] do not apply. When applying the receiving rules in Section 9.2, IPv6 packets are as well protected against spoofing as IPv4 packets are within an SP network. A malicious user that is aware of a 6rd domain and the BR IPv4 address could use this information to construct a packet that would cause a Border Relay to reflect tunneled packets outside of the domain that it is serving. If the attacker constructs the packet accordingly and can inject a packet with an IPv6 source address that looks as if it originates from within another 6rd domain, forwarding loops between 6rd domains may be created, allowing the malicious user to launch a packet amplification attack between 6rd domains [RoutingLoop]. One possible mitigation for this is to simply not allow the BR IPv4 address to be reachable from outside the SP's 6rd domain. In this case, carefully constructed IPv6 packets still could be reflected off a single BR, but the looping condition will not occur. Tunneled packets with the BR IPv4 address as the source address might also be filtered to prohibit 6rd tunnels from exiting the 6rd domain. Townsley & Troan Standards Track [Page 15] RFC 5969 6rd August 2010 To avoid forwarding loops via other internal relays, the BR should employ outgoing and incoming IPv4 packets filters, filtering out all known relay addresses for internal 6rd BRs, ISATAP routers, or 6to4 relays, including the well-known anycast address space for 6to4. Another possible mitigation to the routing loop issue is described in [V6OPS-LOOPS]. The BR MUST install a null route [RFC4632] for its 6rd delegated prefix created based on its BR IPv4 address, with the exception of the IPv6 Subnet-Router anycast address. 13. IANA Considerations IANA assigned a new DHCP Option code point for OPTION_6RD (212) with a data length of 18 + N (OPTION_6RD with N/4 6rd BR addresses). 14. Acknowledgements This RFC is based on Remi Despres' original idea described in [RFC5569] and the work done by Rani Assaf, Alexandre Cassen, and Maxime Bizon at Free Telecom. Brian Carpenter and Keith Moore documented 6to4, which all of this work is based upon. We thank Fred Templin for his review and contributions, and for sharing his experience with ISATAP. Review and encouragement have been provided by many others and in particular Chris Chase, Thomas Clausen, Wouter Cloetens, Wojciech Dec, Bruno Decraene, Remi Despres, Alain Durand, Washam Fan, Martin Gysi, David Harrington, Jerry Huang, Peter McCann, Alexey Melnikov, Dave Thaler, Eric Voit, and David Ward. 15. References 15.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999. Townsley & Troan Standards Track [Page 16] RFC 5969 6rd August 2010 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 15.2. Informative References [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. Townsley & Troan Standards Track [Page 17] RFC 5969 6rd August 2010 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. [RoutingLoop] Nakibly and Arov, "Routing Loop Attacks using IPv6 Tunnels", August 2009, <http://www.usenix.org/event/ woot09/tech/full_papers/nakibly.pdf>. [TR069] "TR-069, CPE WAN Management Protocol v1.1, Version: Issue 1 Amendment 2", December 2007. [V6OPS-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", Work in Progress, May 2010. Authors' Addresses Mark Townsley Cisco Paris, France EMail: mark@townsley.net Ole Troan Cisco Bergen, Norway EMail: ot@cisco.com Townsley & Troan Standards Track [Page 18] </pre>

IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Protocol Specification

Internet Engineering Task Force (IETF) W. Townsley Request for Comments: 5969 ...

Read more »

IPv6 Addressing of IPv4/IPv6 Translators

<pre> Internet Engineering Task Force (IETF) C. Bao Request for Comments: 6052 CERNET Center/Tsinghua University Updates: 4291 C. Huitema Category: Standards Track Microsoft Corporation ISSN: 2070-1721 M. Bagnulo UC3M M. Boucadair France Telecom X. Li CERNET Center/Tsinghua University October 2010 IPv6 Addressing of IPv4/IPv6 Translators Abstract This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6052. Bao, et al. Standards Track [Page 1] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 5 2.1. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 5 2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 5 2.3. Address Translation Algorithms . . . . . . . . . . . . . . 7 2.4. Text Representation . . . . . . . . . . . . . . . . . . . 7 3. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 8 3.1. Restrictions on the Use of the Well-Known Prefix . . . . . 8 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8 3.3. Choice of Prefix for Stateless Translation Deployments . . 9 3.4. Choice of Prefix for Stateful Translation Deployments . . 11 4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12 4.2. Choice of the Well-Known Prefix . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.1. Protection against Spoofing . . . . . . . . . . . . . . . 14 5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 15 5.3. Firewall Configuration . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Bao, et al. Standards Track [Page 2] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 1. Introduction This document is part of a series of IPv4/IPv6 translation documents. A framework for IPv4/IPv6 translation is discussed in [v4v6-FRAMEWORK], including a taxonomy of scenarios that will be used in this document. Other documents specify the behavior of various types of translators and gateways, including mechanisms for translating between IP headers and other types of messages that include IP addresses. This document specifies how an individual IPv6 address is translated to a corresponding IPv4 address, and vice versa, in cases where an algorithmic mapping is used. While specific types of devices are used herein as examples, it is the responsibility of the specification of such devices to reference this document for algorithmic mapping of the addresses themselves. Section 2 describes the prefixes and the format of "IPv4-embedded IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an IPv4 address. This format is common to both "IPv4-converted" and "IPv4-translatable" IPv6 addresses. This section also defines the algorithms for translating addresses, and the text representation of IPv4-embedded IPv6 addresses. Section 3 discusses the choice of prefixes, the conditions in which they can be used, and the use of IPv4-embedded IPv6 addresses with stateless and stateful translation. Section 4 provides a summary of the discussions behind two specific design decisions, the choice of a null suffix and the specific value of the selected prefix. Section 5 discusses security concerns. In some scenarios, a dual-stack host will unnecessarily send its traffic through an IPv6/IPv4 translator. This can be caused by the host's default address selection algorithm [RFC3484], referrals, or other reasons. Optimizing these scenarios for dual-stack hosts is for future study. 1.1. Applicability Scope This document is part of a series defining address translation services. We understand that the address format could also be used by other interconnection methods between IPv6 and IPv4, e.g., methods based on encapsulation. If encapsulation methods are developed by the IETF, we expect that their descriptions will document their specific use of IPv4-embedded IPv6 addresses. Bao, et al. Standards Track [Page 3] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 1.2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.3. Terminology This document makes use of the following terms: Address translator: any entity that has to derive an IPv4 address from an IPv6 address or vice versa. This applies not only to devices that do IPv4/IPv6 packet translation, but also to other entities that manipulate addresses, such as name resolution proxies (e.g., DNS64 [DNS64]) and possibly other types of Application Layer Gateways (ALGs). IPv4-converted IPv6 addresses: IPv6 addresses used to represent IPv4 nodes in an IPv6 network. They are a variant of IPv4-embedded IPv6 addresses and follow the format described in Section 2.2. IPv4-embedded IPv6 addresses: IPv6 addresses in which 32 bits contain an IPv4 address. Their format is described in Section 2.2. IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6 packets, and vice versa. It may do "stateless" translation, meaning that there is no per-flow state required, or "stateful" translation, meaning that per-flow state is created when the first packet in a flow is received. IPv4-translatable IPv6 addresses: IPv6 addresses assigned to IPv6 nodes for use with stateless translation. They are a variant of IPv4-embedded IPv6 addresses and follow the format described in Section 2.2. Network-Specific Prefix: an IPv6 prefix assigned by an organization for use in algorithmic mapping. Options for the Network-Specific Prefix are discussed in Sections 3.3 and 3.4. Well-Known Prefix: the IPv6 prefix defined in this document for use in an algorithmic mapping. Bao, et al. Standards Track [Page 4] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 2. IPv4-Embedded IPv6 Address Prefix and Format 2.1. Well-Known Prefix This document reserves a "Well-Known Prefix" for use in an algorithmic mapping. The value of this IPv6 prefix is: 64:ff9b::/96 2.2. IPv4-Embedded IPv6 Address Format IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses follow the same format, described here as the IPv4-embedded IPv6 address Format. IPv4-embedded IPv6 addresses are composed of a variable-length prefix, the embedded IPv4 address, and a variable- length suffix, as presented in the following diagram, in which PL designates the prefix length: +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |32| prefix |v4(32) | u | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |40| prefix |v4(24) | u |(8)| suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |48| prefix |v4(16) | u | (16) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |56| prefix |(8)| u | v4(24) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |64| prefix | u | v4(32) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |96| prefix | v4(32) | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 1 In these addresses, the prefix shall be either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to the organization deploying the address translators. The prefixes can only have one of the following lengths: 32, 40, 48, 56, 64, or 96. (The Well-Known Prefix is 96 bits long, and can only be used in the last form of the table.) Various deployments justify different prefix lengths with Network- Specific Prefixes. The trade-off between different prefix lengths are discussed in Sections 3.3 and 3.4. Bao, et al. Standards Track [Page 5] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 Bits 64 to 71 of the address are reserved for compatibility with the host identifier format defined in the IPv6 addressing architecture [RFC4291]. These bits MUST be set to zero. When using a /96 Network-Specific Prefix, the administrators MUST ensure that the bits 64 to 71 are set to zero. A simple way to achieve that is to construct the /96 Network-Specific Prefix by picking a /64 prefix, and then adding 4 octets set to zero. The IPv4 address is encoded following the prefix, most significant bits first. Depending of the prefix length, the 4 octets of the address may be separated by the reserved octet "u", whose 8 bits MUST be set to zero. In particular: o When the prefix is 32 bits long, the IPv4 address is encoded in positions 32 to 63. o When the prefix is 40 bits long, 24 bits of the IPv4 address are encoded in positions 40 to 63, with the remaining 8 bits in position 72 to 79. o When the prefix is 48 bits long, 16 bits of the IPv4 address are encoded in positions 48 to 63, with the remaining 16 bits in position 72 to 87. o When the prefix is 56 bits long, 8 bits of the IPv4 address are encoded in positions 56 to 63, with the remaining 24 bits in position 72 to 95. o When the prefix is 64 bits long, the IPv4 address is encoded in positions 72 to 103. o When the prefix is 96 bits long, the IPv4 address is encoded in positions 96 to 127. There are no remaining bits, and thus no suffix, if the prefix is 96 bits long. In the other cases, the remaining bits of the address constitute the suffix. These bits are reserved for future extensions and SHOULD be set to zero. Address translators who receive IPv4- embedded IPv6 addresses where these bits are not zero SHOULD ignore the bits' value and proceed as if the bits' value were zero. (Future extensions may specify a different behavior.) Bao, et al. Standards Track [Page 6] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 2.3. Address Translation Algorithms IPv4-embedded IPv6 addresses are composed according to the following algorithm: o Concatenate the prefix, the 32 bits of the IPv4 address, and the suffix (if needed) to obtain a 128-bit address. o If the prefix length is less than 96 bits, insert the null octet "u" at the appropriate position (bits 64 to 71), thus causing the least significant octet to be excluded, as documented in Figure 1. The IPv4 addresses are extracted from the IPv4-embedded IPv6 addresses according to the following algorithm: o If the prefix is 96 bits long, extract the last 32 bits of the IPv6 address; o For the other prefix lengths, remove the "u" octet to obtain a 120-bit sequence (effectively shifting bits 72-127 to positions 64-119), then extract the 32 bits following the prefix. 2.4. Text Representation IPv4-embedded IPv6 addresses will be represented in text in conformity with Section 2.2 of [RFC4291]. IPv4-embedded IPv6 addresses constructed using the Well-Known Prefix or a /96 Network- Specific Prefix may be represented using the alternative form presented in Section 2.2 of [RFC4291], with the embedded IPv4 address represented in dotted decimal notation. Examples of such representations are presented in Tables 1 and 2. +-----------------------+------------+------------------------------+ | Network-Specific | IPv4 | IPv4-embedded IPv6 address | | Prefix | address | | +-----------------------+------------+------------------------------+ | 2001:db8::/32 | 192.0.2.33 | 2001:db8:c000:221:: | | 2001:db8:100::/40 | 192.0.2.33 | 2001:db8:1c0:2:21:: | | 2001:db8:122::/48 | 192.0.2.33 | 2001:db8:122:c000:2:2100:: | | 2001:db8:122:300::/56 | 192.0.2.33 | 2001:db8:122:3c0:0:221:: | | 2001:db8:122:344::/64 | 192.0.2.33 | 2001:db8:122:344:c0:2:2100:: | | 2001:db8:122:344::/96 | 192.0.2.33 | 2001:db8:122:344::192.0.2.33 | +-----------------------+------------+------------------------------+ Table 1: Text Representation of IPv4-Embedded IPv6 Addresses Using Network-Specific Prefixes Bao, et al. Standards Track [Page 7] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 +-------------------+--------------+----------------------------+ | Well-Known Prefix | IPv4 address | IPv4-Embedded IPv6 address | +-------------------+--------------+----------------------------+ | 64:ff9b::/96 | 192.0.2.33 | 64:ff9b::192.0.2.33 | +-------------------+--------------+----------------------------+ Table 2: Text Representation of IPv4-Embedded IPv6 Addresses Using the Well-Known Prefix The Network-Specific Prefix examples in Table 1 are derived from the IPv6 prefix reserved for documentation in [RFC3849]. The IPv4 address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for documentation in [RFC5735]. The representation of IPv6 addresses is compatible with [RFC5952]. 3. Deployment Guidelines 3.1. Restrictions on the Use of the Well-Known Prefix The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. Address translators MUST NOT translate packets in which an address is composed of the Well-Known Prefix and a non- global IPv4 address; they MUST drop these packets. The Well-Known Prefix SHOULD NOT be used to construct IPv4- translatable IPv6 addresses. The nodes served by IPv4-translatable IPv6 addresses should be able to receive global IPv6 traffic bound to their IPv4-translatable IPv6 address without incurring intermediate protocol translation. This is only possible if the specific prefix used to build the IPv4-translatable IPv6 addresses is advertised in inter-domain routing, but the advertisement of more specific prefixes derived from the Well-Known Prefix is not supported, as explained in Section 3.2. Network-Specific Prefixes SHOULD be used in these scenarios, as explained in Section 3.3. The Well-Known Prefix MAY be used by organizations deploying translation services, as explained in Section 3.4. 3.2. Impact on Inter-Domain Routing The Well-Known Prefix MAY appear in inter-domain routing tables, if service providers decide to provide IPv6-IPv4 interconnection services to peers. Advertisement of the Well-Known Prefix SHOULD be controlled either by upstream and/or downstream service providers according to inter-domain routing policies, e.g., through Bao, et al. Standards Track [Page 8] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 configuration of BGP [RFC4271]. Organizations that advertise the Well-Known Prefix in inter-domain routing MUST be able to provide IPv4/IPv6 translation service. When the IPv4/IPv6 translation relies on the Well-Known Prefix, IPv4- embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be advertised in BGP (especially External BGP) [RFC4271] because this leads to importing the IPv4 routing table into the IPv6 one and therefore introduces scalability issues to the global IPv6 routing table. Administrators of BGP nodes SHOULD configure filters that discard advertisements of embedded IPv6 prefixes longer than the Well-Known Prefix. When the IPv4/IPv6 translation service relies on Network-Specific Prefixes, the IPv4-translatable IPv6 prefixes used in stateless translation MUST be advertised with proper aggregation to the IPv6 Internet. Similarly, if translators are configured with multiple Network-Specific Prefixes, these prefixes MUST be advertised to the IPv6 Internet with proper aggregation. 3.3. Choice of Prefix for Stateless Translation Deployments Organizations may deploy translation services using stateless translation. In these deployments, internal IPv6 nodes are addressed using IPv4-translatable IPv6 addresses, which enable them to be accessed by IPv4 nodes. The addresses of these external IPv4 nodes are then represented in IPv4-converted IPv6 addresses. Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix to their IPv4/IPv6 translation service. IPv4-translatable and IPv4-converted IPv6 addresses MUST be constructed as specified in Section 2.2. IPv4-translatable IPv6 addresses MUST use the selected Network-Specific Prefix. Both IPv4- translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix. Using the same prefix ensures that IPv6 nodes internal to the organization will use the most efficient paths to reach the nodes served by IPv4-translatable IPv6 addresses. Specifically, if a node learns the IPv4 address of a target internal node without knowing that this target is in fact located behind the same translator that the node also uses, translation rules will ensure that the IPv6 address constructed with the Network-Specific Prefix is the same as the IPv4-translatable IPv6 address assigned to the target. Standard routing preference (i.e., "most specific match wins") will then ensure that the IPv6 packets are delivered directly, without requiring that translators receive the packets and then return them in the direction from which they came. Bao, et al. Standards Track [Page 9] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 The intra-domain routing protocol must be able to deliver packets to the nodes served by IPv4-translatable IPv6 addresses. This may require routing on some or all of the embedded IPv4 address bits. Security considerations detailed in Section 5 require that routers check the validity of the IPv4-translatable IPv6 source addresses, using some form of reverse path check. The management of stateless address translation can be illustrated with a small example: We will consider an IPv6 network with the prefix 2001:db8: 122::/48. The network administrator has selected the Network- Specific Prefix 2001:db8:122:344::/64 for managing stateless IPv4/ IPv6 translation. The IPv4-translatable address block for IPv4 subnet 192.0.2.0/24 is 2001:db8:122:344:c0:2::/96. In this network, the host A is assigned the IPv4-translatable IPv6 address 2001:db8:122:344:c0:2:2100::, which corresponds to the IPv4 address 192.0.2.33. Host A's address is configured either manually or through DHCPv6. In this example, host A is not directly connected to the translator, but instead to a link managed by a router R. The router R is configured to forward to A the packets bound to 2001: db8:122:344:c0:2:2100::. To receive these packets, R will advertise reachability of the prefix 2001:db8:122:344:c0:2:2100::/ 104 in the intra-domain routing protocol -- or perhaps a shorter prefix if many hosts on link have IPv4-translatable IPv6 addresses derived from the same IPv4 subnet. If a packet bound to 192.0.2.33 reaches the translator, the destination address will be translated to 2001:db8:122:344:c0:2:2100::, and the packet will be routed towards R and then to A. Let's suppose now that a host B of the same domain learns the IPv4 address of A, maybe through an application-specific referral. If B has translation-aware software, B can compose a destination address by combining the Network-Specific Prefix 2001:db8:122: 344::/64 and the IPv4 address 192.0.2.33, resulting in the address 2001:db8:122:344:c0:2:2100::. The packet sent by B will be forwarded towards R, and then to A, avoiding protocol translation. Forwarding, and reverse path checks, are more efficient when performed on the combination of the prefix and the IPv4 address. In theory, routers are able to route on prefixes of any length, but in practice there may be routers for which routing on prefixes larger than 64 bits is slower. However, routing efficiency is not the only consideration in the choice of a prefix length. Organizations also need to consider the availability of prefixes, and the potential impact of all-zero identifiers. Bao, et al. Standards Track [Page 10] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 If a /32 prefix is used, all the routing bits are contained in the top 64 bits of the IPv6 address, leading to excellent routing properties. These prefixes may however be hard to obtain, and allocation of a /32 to a small set of IPv4-translatable IPv6 addresses may be seen as wasteful. In addition, the /32 prefix and a zero suffix lead to an all-zero interface identifier, which is an issue that we discuss in Section 4.1. Intermediate prefix lengths such as /40, /48, or /56 appear as compromises. Only some of the IPv4 bits are part of the /64 prefixes. Reverse path checks, in particular, may have a limited efficiency. Reverse path checks limited to the most significant bits of the IPv4 address will reduce the possibility of spoofing external IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4- translatable IPv6 addresses. We propose a compromise, based on using no more than 1/256th of an organization's allocation of IPv6 addresses for the IPv4/IPv6 translation service. For example, if the organization is an Internet Service Provider with an allocated IPv6 prefix /32 or shorter, the ISP could dedicate a /40 prefix to the translation service. An end site with a /48 allocation could dedicate a /56 prefix to the translation service, or possibly a /96 prefix if all IPv4- translatable IPv6 addresses are located on the same link. The recommended prefix length is also a function of the deployment scenario. The stateless translation can be used for Scenario 1, Scenario 2, Scenario 5, and Scenario 6 defined in [v4v6-FRAMEWORK]. For different scenarios, the prefix length recommendations are: o For Scenario 1 (an IPv6 network to the IPv4 Internet) and Scenario 2 (the IPv4 Internet to an IPv6 network), an ISP holding a /32 allocation SHOULD use a /40 prefix, and a site holding a /48 allocation SHOULD use a /56 prefix. o For Scenario 5 (an IPv6 network to an IPv4 network) and Scenario 6 (an IPv4 network to an IPv6 network), the deployment SHOULD use a /64 or a /96 prefix. 3.4. Choice of Prefix for Stateful Translation Deployments Organizations may deploy translation services based on stateful translation technology. An organization may decide to use either a Network-Specific Prefix or the Well-Known Prefix for its stateful IPv4/IPv6 translation service. Bao, et al. Standards Track [Page 11] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 When these services are used, IPv6 nodes are addressed through standard IPv6 addresses, while IPv4 nodes are represented by IPv4- converted IPv6 addresses, as specified in Section 2.2. The stateful nature of the translation creates a potential stability issue when the organization deploys multiple translators. If several translators use the same prefix, there is a risk that packets belonging to the same connection may be routed to different translators as the internal routing state changes. This issue can be avoided either by assigning different prefixes to different translators or by ensuring that all translators using the same prefix coordinate their state. Stateful translation can be used in scenarios defined in [v4v6-FRAMEWORK]. The Well-Known Prefix SHOULD be used in these scenarios, with two exceptions: o In all scenarios, the translation MAY use a Network-Specific Prefix, if deemed appropriate for management reasons. o The Well-Known Prefix MUST NOT be used for Scenario 3 (the IPv6 Internet to an IPv4 network), as this would lead to using the Well-Known Prefix with non-global IPv4 addresses. That means a Network-Specific Prefix (for example, a /96 prefix) MUST be used in that scenario. 4. Design Choices The prefix that we have chosen reflects two design choices, the null suffix and the specific value of the Well-Known Prefix. We provide here a summary of the discussions leading to those two choices. 4.1. Choice of Suffix The address format described in Section 2.2 recommends a zero suffix. Before making this recommendation, we considered different options: checksum neutrality, the encoding of a port range, and a value different than 0. In the case of stateless translation, there would be no need for the translator to recompute a one's complement checksum if both the IPv4- translatable and the IPv4-converted IPv6 addresses were constructed in a "checksum-neutral" manner, that is, if the IPv6 addresses would have the same one's complement checksum as the embedded IPv4 address. In the case of stateful translation, checksum neutrality does not eliminate checksum computation during translation, as only one of the two addresses would be checksum neutral. We considered reserving 16 bits in the suffix to guarantee checksum neutrality, but declined Bao, et al. Standards Track [Page 12] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 because it would not help with stateful translation and because checksum neutrality can also be achieved by an appropriate choice of the Network-Specific Prefix, i.e., selecting a prefix whose one's complement checksum equals either 0 or 0xffff. There have been proposals to complement stateless translation with a port-range feature. Instead of mapping an IPv4 address to exactly one IPv6 prefix, the options would allow several IPv6 nodes to share an IPv4 address, with each node managing a different range of ports. If a port range extension is needed, it could be defined later, using bits currently reserved as null in the suffix. When a /32 prefix is used, an all-zero suffix results in an all-zero interface identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet- router anycast address. However, in our specification, there is only one node with an IPv4-translatable IPv6 address in the /64 subnet, so the anycast semantic does not create confusion. We thus decided to keep the null suffix for now. This issue does not exist for prefixes larger than 32 bits, such as the /40, /56, /64, and /96 prefixes that we recommend in Section 3.3. 4.2. Choice of the Well-Known Prefix Before making our recommendation of the Well-Known Prefix, we were faced with three choices: o reuse the IPv4-mapped prefix, ::ffff:0:0/96, as specified in RFC 2765, Section 2.1; o request IANA to allocate a /32 prefix, or o request allocation of a new /96 prefix. We weighted the pros and cons of these choices before settling on the recommended /96 Well-Known Prefix. The main advantage of the existing IPv4-mapped prefix is that it is already defined. Reusing that prefix would require minimal standardization efforts. However, being already defined is not just an advantage, as there may be side effects of current implementations. When presented with the IPv4-mapped prefix, current versions of Windows and Mac OS generate IPv4 packets, but will not send IPv6 packets. If we used the IPv4-mapped prefix, these nodes would not be able to support translation without modification. This will defeat the main purpose of the translation techniques. We thus eliminated the first choice, i.e., decided to not reuse the IPv4- mapped prefix, ::ffff:0:0/96. Bao, et al. Standards Track [Page 13] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 A /32 prefix would have allowed the embedded IPv4 address to fit within the top 64 bits of the IPv6 address. This would have facilitated routing and load balancing when an organization deploys several translators. However, such destination-address-based load balancing may not be desirable. It is not compatible with Session Traversal Utilities for NAT (STUN) [RFC5389] in the deployments involving multiple stateful translators, each one having a different pool of IPv4 addresses. STUN compatibility would only be achieved if the translators managed the same pool of IPv4 addresses and were able to coordinate their translation state, in which case there is no big advantage to using a /32 prefix rather than a /96 prefix. According to Section 2.2 of [RFC4291], in the legal textual representations of IPv6 addresses, dotted decimal can only appear at the end. The /96 prefix is compatible with that requirement. It enables the dotted decimal notation without requiring an update to [RFC4291]. This representation makes the address format easier to use and the log files easier to read. The prefix that we recommend has the particularity of being "checksum neutral". The sum of the hexadecimal numbers "0064" and "ff9b" is "ffff", i.e., a value equal to zero in one's complement arithmetic. An IPv4-embedded IPv6 address constructed with this prefix will have the same one's complement checksum as the embedded IPv4 address. 5. Security Considerations 5.1. Protection against Spoofing IPv4/IPv6 translators can be modeled as special routers, are subject to the same risks, and can implement the same mitigations. (The discussion of generic threats to routers and their mitigations is beyond the scope of this document.) There is, however, a particular risk that directly derives from the practice of embedding IPv4 addresses in IPv6: address spoofing. An attacker could use an IPv4-embedded IPv6 address as the source address of malicious packets. After translation, the packets will appear as IPv4 packets from the specified source, and the attacker may be hard to track. If left without mitigation, the attack would allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses. The mitigation is to implement reverse path checks and to verify throughout the network that packets are coming from an authorized location. Bao, et al. Standards Track [Page 14] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 5.2. Secure Configuration The prefixes used for address translation are used by IPv6 nodes to send packets to IPv6/IPv4 translators. Attackers could attempt to fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong values for these parameters, resulting in network disruption, denial of service, and possible information disclosure. To mitigate such attacks, network administrators need to ensure that prefixes are configured in a secure way. The mechanisms for achieving secure configuration of prefixes are beyond the scope of this document. 5.3. Firewall Configuration Many firewalls and other security devices filter traffic based on IPv4 addresses. Attackers could attempt to fool these firewalls by sending IPv6 packets to or from IPv6 addresses that translate to the filtered IPv4 addresses. If the attack is successful, traffic that was previously blocked might be able to pass through the firewalls disguised as IPv6 packets. In all such scenarios, administrators should assure that packets that send to or from IPv4-embedded IPv6 addresses are subject to the same filtering as those directly sent to or from the embedded IPv4 addresses. The mechanisms for configuring firewalls and security devices to achieve this filtering are beyond the scope of this document. 6. IANA Considerations IANA has made the following changes in the "Internet Protocol Version 6 Address Space" registry located at http://www.iana.org. OLD: IPv6 Prefix Allocation Reference Note ----------- ---------------- ------------ ---------------- 0000::/8 Reserved by IETF [RFC4291] [1][5] NEW: IPv6 Prefix Allocation Reference Note ----------- ---------------- ------------ ---------------- 0000::/8 Reserved by IETF [RFC4291] [1][5][6] [6] The "Well-Known Prefix" 64:ff9b::/96 used in an algorithmic mapping between IPv4 to IPv6 addresses is defined out of the 0000::/8 address block, per RFC 6052. Bao, et al. Standards Track [Page 15] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 7. Acknowledgements Many people in the BEHAVE WG have contributed to the discussion that led to this document, including Andrew Sullivan, Andrew Yourtchenko, Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler, David Harrington, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-Courmont, Remi Despres, and William Waites. Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program. 8. Contributors The following individuals co-authored documents from which text has been incorporated, and are listed in alphabetical order. Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: +1 425 703 8835 EMail: dthaler@microsoft.com Fred Baker Cisco Systems Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com Hiroshi Miyata Yokogawa Electric Corporation 2-9-32 Nakacho Musashino-shi, Tokyo 180-8750 JAPAN EMail: h.miyata@jp.yokogawa.com Bao, et al. Standards Track [Page 16] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 9.2. Informative References [DNS64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", Work in Progress, October 2010. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010. [v4v6-FRAMEWORK] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", Work in Progress, August 2010. Bao, et al. Standards Track [Page 17] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 Authors' Addresses Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China Phone: +86 10-62785983 EMail: congxiao@cernet.edu.cn Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 U.S.A. EMail: huitema@microsoft.com Marcelo Bagnulo UC3M Av. Universidad 30 Leganes, Madrid 28911 Spain Phone: +34-91-6249500 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es/marcelo Mohamed Boucadair France Telecom 3, Av Francois Chateaux Rennes 350000 France EMail: mohamed.boucadair@orange-ftgroup.com Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China Phone: +86 10-62785983 EMail: xing@cernet.edu.cn Bao, et al. Standards Track [Page 18] </pre>

IPv6 Addressing of IPv4/IPv6 Translators

Internet Engineering Task Force (IETF) C. Bao Request for Comments: 6052 CERNET Center/Tsinghua U...

Read more »