Skip to main content

OSPFv3 over IPv4 for IPv6 Transition
draft-chen-ospf-transition-to-ospfv3-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Ing-Wher (Helen) Chen , Acee Lindem
Last updated 2014-01-27
Replaced by draft-ietf-ospf-transition-to-ospfv3, RFC 7949
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chen-ospf-transition-to-ospfv3-00
Internet Draft                                                   I. Chen
<draft-chen-ospf-transition-to-ospfv3-00.txt>                  A. Lindem
Category: Informational                                         Ericsson
Expires in 6 months                                     January 26, 2014

                  OSPFv3 over IPv4 for IPv6 Transition
             <draft-chen-ospf-transition-to-ospfv3-00.txt>

Status of this Memo

   Distribution of this memo is unlimited.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on date.

Copyright Notice

   Copyright (c) 2014 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.

Abstract

   This draft defines a mechanism to use IPv4 to transport OSPFv3

I. Chen & A. Lindem        Expires in 6 months                  [Page 1]
Internet Draft            transition-to-ospfv3          January 26, 2014

   packets, in order to facilitate transition from IPv4-only to IPv6 and
   dual-stack within a routing domain.  Using OSPFv3 over IPv4 with the
   existing OSPFv3 Address Family extension simplifies transition from
   an OSFPv2 IPv4-only routing domain to an OSPFv3 dual-stack routing
   domain, and later possibly to an IPv6-only routing domain.

I. Chen & A. Lindem        Expires in 6 months                  [Page 2]
Internet Draft            transition-to-ospfv3          January 26, 2014

Table of Contents

   1. Introduction ....................................................3
   2. Encapsulation in IPv4 ...........................................4
      2.1. Source Address .............................................6
      2.2. Destination ................................................6
      2.3. Operation over Virtual Link ................................6
   3. Security Considerations .........................................7
   4. IANA Considerations .............................................7
   5. References ......................................................7

1.  Introduction

   To facilitate transition from IPv4 [RFC791] to IPv6 [RFC2460], dual-
   stack or IPv6 routing protocols should be gradually deployed.  Dual-
   stack routing protocols, such as Border Gateway Protocol [RFC4271],
   have an advantage during the transition, because both IPv4 and IPv6
   topologies can be transported using either IPv4 or IPv6.  Some
   IPv4-specific and IPv6-specific routing protocols share enough
   similarities in their protocol packet formats and protocol signaling
   that it is trivial to build an initial IPv6 routing domain over IPv4,
   allowing IPv6 routing domains be deployed and tested before de-
   commissioning IPv4 and moving to an IPv6-only network.

   In the case of Open Shortest Path First (OSPF) interior gateway
   routing protocol (IGP), OSPFv2 [RFC2328] is the IGP deployed over
   IPv4, while OSPFv3 [RFC5340] is the IGP deployed over IPv6.  OSPFv3
   further supports multiple address families [RFC5838], including both
   the IPv6 unicast address family and the IPv4 unicast address family.
   Consequently, it is possible to deploy OSPFv3 over IPv4 without any
   changes to to either OSPFv3 or IPv4.

   This draft specifies how to use IPv4 packets to transport OSPFv3
   packets.  The mechanism takes advantage of the fact that OSPFv2 and
   OSPFv3 share the same IP protocol number, 89.  Additionally, OSPFv2
   and OSPFv3 also share the same OSPF packet header format, while the
   OSPF packet header has its own OSPF version number that distinguishes
   an OSPFv2 packet from an OSPFv3 packet.

   In normal operation, it is expected that the IPv4 topology within the
   OSPF domain will be congruent with the IPv6 topology of that OSPF
   domain.  In such cases, it is expected that either all OSPFv3 packets
   will be carried over IPv4 or that all OSPFv3 packets will be carried
   over IPv6.

   If the IPv4 topology and IPv6 topology are not identical, the most
   likely cause (as of the date this draft was written) is that some
   parts of the network deployment are not yet upgraded to support both

I. Chen & A. Lindem        Expires in 6 months                  [Page 3]
Internet Draft            transition-to-ospfv3          January 26, 2014

   IPv4 and IPv6.  In situations where the IPv4 deployment is a proper
   superset of the IPv6 deployment, it is expected that OSPFv3 packets
   would be carried over IPv4, until the rest of the network deployment
   is upgraded to support IPv6 in addition to IPv4.  In situations where
   the IPv6 deployment is a proper superset of the IPv4 deployment, for
   example as IPv4 is phased out, it is expected that OSPFv3 would be
   carried over IPv6.

   Throughout this document, OSPF is used when the text applies to both
   OSPFv2 and OSPFv3.  OSPFv2 or OSPFv3 is used when the text is
   specific to one version of the OSPF protocol.  Similarly, IP is used
   when the text describes either version of the Internet protocol.
   IPv4 or IPv6 is used when the text is specific to a single version of
   the protocol.

2.  Encapsulation in IPv4

   Unlike 6to4 encapsulation [RFC3056] that tunnels IPv6 traffic through
   an IPv4 network, this draft proposes that an OSPFv3 packet be
   directly encapsulated within an IPv4 packet as the payload, without
   the IPv6 packet header, as illustrated in Figure 1.  In this case,
   the IPv4 packet has an IPv4 protocol type of 89, denoting that the
   payload is an OSPF packet.  The payload of the IPv4 packet consists
   of an OSPFv3 packet, beginning with the OSPF packet header, in which
   the OSPF version number is 3.

   An OSPFv3 packet followed by a OSPF link-local signaling (LLS)
   extension data block [RFC5613] encapsulated in an IPv4 packet is
   illustrated in Figure 2.

I. Chen & A. Lindem        Expires in 6 months                  [Page 4]
Internet Draft            transition-to-ospfv3          January 26, 2014

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ^
|   4   |  IHL  |Type of Service|          Total Length         |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|         Identification        |Flags|      Fragment Offset    |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live | Protocol 89   |         Header Checksum       | IPv4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                    Destination Address                        |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                    Options                    |    Padding    |  v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ^
|       3       |     Type      |         Packet length         |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Router ID                             | OSPFv3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
|                          Area ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|          Checksum             |  Instance ID  |      0        |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  v
|                        OSPFv3 Body ...                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 1: An IPv4 packet encapsulating an OSPFv3 packet.

                      +---------------+
                      | IPv4 Header   |
                      +---------------+
                      | OSPFv3 Header |
                      |...............|
                      |               |
                      | OSPFv3 Body   |
                      |               |
                      +---------------+
                      |               |
                      | LLS Data      |
                      |               |
                      +---------------+

     Figure 2: The IPv4 packet encapsulating an OSPFv3 packet with
               a trailing OSPF link-local signaling data block.

I. Chen & A. Lindem        Expires in 6 months                  [Page 5]
Internet Draft            transition-to-ospfv3          January 26, 2014

2.1.  Source Address

     Consistent with OSPFv2, the IPv4 source address of an OSPF protocol
     packet is one end of a router adjacency.  For OSPFv3 over IPv4, the
     source address is the IPv4 unicast address of the interface
     transmitting the packet.

2.2.  Destination Address

     As defined in OSPFv2, the IPv4 destination address of an OSPF
     protocol packet is either an IPv4 multicast address or the IPv4
     unicast address of the other end of the adjacency.  Two well-known
     link-local multicast addresses are assigned to OSPFv2, the
     AllSPFRouters address 224.0.0.5 and the AllDRouters address
     224.0.0.6.  The multicast address used depends on the OSPF packet
     type, the OSPF interface type, and the OSPF router's role on the
     multi-access networks.

     Thus, for an OSPFv3 over IPv4 packet to be sent to AllSPFRouters,
     the destination address field in the IPv4 packet should be
     224.0.0.5.  For an OSPFv3 over IPv4 packet to be sent to
     AllDRouters, the destination address field in the IPv4 packet
     should be 224.0.0.6.

     When an OSPF router sends a unicast OSPF packet over a connected
     interface, the destination of such an IP packet is the address
     assigned to the receiving interface.  Thus, a unicast OSPFv3 packet
     carried in an IPv4 packet would specify the IPv4 unicast address of
     the receiving interface as the destination address.

2.3.  Operation over Virtual Link

     When an OSPF router sends an OSPF packet over a virtual link, the
     receiving router is a router which is not directly connected to the
     sending router.  Thus, the destination IP address of the IP packet
     must be a reachable unicast IP address of the receiving router.
     Because IPv6 is the presumed Internet protocol and an IPv4
     destination is not routable, OSPFv3 address family extension
     [RFC5838] specifies that only IPv6 address family virtual links are
     supported.

     As illustrated in Figure 1, this draft proposes that an OSPFv3
     packet be carried within an IPv4 packet.  As a result, an IPv4
     packet in which the destination field is a unicast IPv4 address
     assigned to the virtual router is routable, and OSPFv3 virtual
     links in IPv4 unicast address families can be supported and the
     restriction in Section 2.8 of RFC 5838 [RFC5838] can be removed.
     If IPv4 transport, as specified herein, is used for IPv6 address

I. Chen & A. Lindem        Expires in 6 months                  [Page 6]
Internet Draft            transition-to-ospfv3          January 26, 2014

     families, virtual links cannot be supported. Hence, it is
     RECOMMENDED to use the IP transport matching the address family in
     OSPF routing domains requiring virtual links.

3. Security Considerations

   As described in [RFC4552], OSPFv3 uses IPsec [RFC4301] for
   authentication and confidentiality.  Consequently, an OSPFv3 packet
   carried within an IPv4 packet requires IPsec to provide
   authentication and confidentiality.  Because IPsec is more commonly
   implemented and more widely available on IPv4 systems than on IPv6
   systems, this use is not more problematic than use of IPsec with
   OSPFv3 over IPv6.  Further work such as [ipsecospf] might be required
   for IPv4 IPsec.

   An optional OSPFv3 Authentication Trailer [RFC6505] also has been
   defined as an alternative to using IPsec.  The calculation of the
   authentication data in the Authentication Trailer includes the source
   IPv6 address to protect an OSPFv3 router from Man-in-the-Middle
   attacks.  For IPv4 encapsulation described in this draft, the IPv4
   source address should be placed in the first 4 bytes of Apad followed
   by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times, where L
   is the length of hash measured in octet.

   The processing of the optional Authentication Trailer is confined
   entirely within the OSPFv3 protocol, in which each OSPFv3 router is
   responsible for the authentication without involvement from IPsec or
   any other IP layer.  Consequently, except for calculation of the
   value Apad, transporting OSPFv3 packets using IPv4 does not change
   the operation of the optional OSPFv3 Authentication Trailer.  At
   present, that Authentication Trailer has limited implementation and
   also limited deployment.

4.  IANA Considerations

   No actions are required from IANA as result of the publication of
   this document.

5.  References

5.1   Normative References

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

I. Chen & A. Lindem        Expires in 6 months                  [Page 7]
Internet Draft            transition-to-ospfv3          January 26, 2014

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.

   [RFC2328]  Moy, J., "OSPF Version 2", STD54, RFC 2328, April 1998.

   [RFC5838]  Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
              R.  Aggarwal, "Support of Address Families in OSPFv3", RFC
              5838, April 2010.

5.2.  Informative References

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
              2006.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC5613]  Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
              Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.

   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
              for OSPFv3", RFC 4552, June 2006.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC6505]  Bhatia, M., Manral, V., and A. Lindem, "Supporting
              Authentication Trailer for OSPFv3", RFC 6506, February
              2012.

   [ipsecospf] Gupta, M. and Melam, M, Work in progress, "draft-gupta-
              ospf-ospfv2-sec-01.txt", August 2009.

Authors' Addresses

   I. Chen
   Ericsson
   Email: ing-wher.chen@ericsson.com

   A. Lindem
   Ericsson
   Email: acee.lindem@ericsson.com

I. Chen & A. Lindem        Expires in 6 months                  [Page 8]