doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7949.txt b/doc/rfc/rfc7949.txt
new file mode 100644
index 0000000..636a004
--- /dev/null
+++ b/doc/rfc/rfc7949.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           I. Chen
+Request for Comments: 7949                                      Ericsson
+Updates: 5838                                                  A. Lindem
+Category: Standards Track                                          Cisco
+ISSN: 2070-1721                                              R. Atkinson
+                                                              Consultant
+                                                             August 2016
+
+
+                  OSPFv3 over IPv4 for IPv6 Transition
+
+Abstract
+
+   This document defines a mechanism to use IPv4 to transport OSPFv3
+   packets.  Using OSPFv3 over IPv4 with the existing OSPFv3 Address
+   Family extension can simplify transition from an OSPFv2 IPv4-only
+   routing domain to an OSPFv3 dual-stack routing domain.  This document
+   updates RFC 5838 to support virtual links in the IPv4 unicast address
+   family when using OSPFv3 over IPv4.
+
+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 7841.
+
+   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/rfc7949.
+
+Copyright Notice
+
+   Copyright (c) 2016 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.
+
+
+
+Chen, et al.                 Standards Track                    [Page 1]
+
+RFC 7949          OSPFv3 over IPv4 for IPv6 Transition       August 2016
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. IPv4-Only Use Case .........................................3
+   2. Requirements Language ...........................................4
+   3. Encapsulation in IPv4 ...........................................4
+      3.1. Source Address .............................................6
+      3.2. Destination Address ........................................6
+      3.3. OSPFv3 Header Checksum .....................................6
+      3.4. Operation over Virtual Links ...............................7
+   4. Management Considerations .......................................7
+      4.1. Coexistence with OSPFv2 ....................................7
+   5. Security Considerations .........................................8
+   6. References ......................................................8
+      6.1. Normative References .......................................8
+      6.2. Informative References .....................................9
+   Acknowledgments ...................................................10
+   Authors' Addresses ................................................11
+
+1.  Introduction
+
+   Using OSPFv3 [RFC5340] over IPv4 [RFC791] with the existing OSPFv3
+   address family extension can simplify transition from an IPv4-only
+   routing domain to an IPv6 [RFC2460] or dual-stack routing domain.
+   Dual-stack routing protocols, such as the Border Gateway Protocol
+   [RFC4271], have an advantage during the transition, because both IPv4
+   and IPv6 address families can be advertised using either IPv4 or IPv6
+   transport.  Some IPv4-specific and IPv6-specific routing protocols
+   share enough similarities in their protocol packet formats and
+   protocol signaling that it is trivial to deploy an initial IPv6
+   routing domain by transporting the routing protocol over IPv4,
+   thereby allowing IPv6 routing domains to be deployed and tested
+   before decommissioning IPv4 and moving to an IPv6-only network.
+
+   In the case of the 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 either OSPFv3 or IPv4.  During the transition to IPv6,
+   future OSPF extensions can focus on OSPFv3, and OSPFv2 can move to
+   maintenance mode.
+
+   This document specifies how to use IPv4 to transport OSPFv3 packets.
+   The mechanism takes advantage of the fact that OSPFv2 and OSPFv3
+   share the same IP protocol number, 89.  Additionally, the OSPF packet
+   header for both OSPFv2 and OSPFv3 includes the OSPF header version
+
+
+
+Chen, et al.                 Standards Track                    [Page 2]
+
+RFC 7949          OSPFv3 over IPv4 for IPv6 Transition       August 2016
+
+
+   (i.e., the field that distinguishes an OSPFv2 packet from an OSPFv3
+   packet) in the same location (i.e., the same offset from the start of
+   the header).
+
+   If the IPv4 topology and IPv6 topology are not identical, the most
+   likely cause is that some parts of the network deployment have not
+   yet been upgraded to support both IPv4 and IPv6.  In situations where
+   the IPv4 deployment is a superset of the IPv6 deployment, it is
+   expected that OSPFv3 packets would be transported 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
+   superset of the IPv4 deployment, it is expected that OSPFv3 would be
+   transported 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 Internet Protocol.
+
+1.1.  IPv4-Only Use Case
+
+   OSPFv3 only requires IPv6 link-local addresses to form adjacencies,
+   and does not require IPv6 global-scope addresses to establish an IPv6
+   routing domain.  However, IPv6 over Ethernet [RFC2464] uses a
+   different EtherType (0x86dd) from IPv4 (0x0800) and the Address
+   Resolution Protocol (ARP) (0x0806) [RFC826] used with IPv4.
+
+   Some existing deployed link-layer equipment only supports IPv4 and
+   ARP.  Such equipment contains hardware filters keyed on the EtherType
+   field of the Ethernet frame to filter which frames will be accepted
+   by that link-layer equipment.  Because IPv6 uses a different
+   EtherType, IPv6 framing for OSPFv3 will not work with that equipment.
+   In other cases, Point-to-Point Protocol (PPP) might be used over a
+   serial interface, but again only IPv4 over PPP might be supported
+   over such an interface.  It is hoped that equipment with such
+   limitations will be eventually upgraded or replaced.
+
+   In some locations, especially locations with less communications
+   infrastructure, satellite communications (SATCOM) are used to reduce
+   deployment costs for data networking.  SATCOM often has lower cost to
+   deploy than running new copper or optical cables over long distances
+   to connect remote areas.  Also, in a wide range of locations
+   including places with good communications infrastructure, Very Small
+   Aperture Terminals (VSATs) often are used by banks and retailers to
+   connect their branches and stores to a central location.
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 3]
+
+RFC 7949          OSPFv3 over IPv4 for IPv6 Transition       August 2016
+
+
+   Some widely deployed VSAT equipment has either (A) Ethernet
+   interfaces that only support the Ethernet Address Resolution Protocol
+   (ARP) and IPv4, or (B) serial interfaces that only support IPv4 and
+   PPP packets.  Such deployments and equipment still can deploy and use
+   OSPFv3 over IPv4 today, and then later migrate to OSPFv3 over IPv6
+   after equipment is upgraded or replaced.  This can have lower
+   operational costs than running OSPFv2 and then trying to make a flag-
+   day switch to OSPFv3.  By running OSPFv3 over IPv4 now, the eventual
+   transition to dual-stack, and then to IPv6-only, can be orchestrated.
+
+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 [RFC2119].
+
+3.  Encapsulation in IPv4
+
+   An OSPFv3 packet can be directly encapsulated within an IPv4 packet
+   as the payload, without the IPv6 packet header, as illustrated in
+   Figure 1.  For OSPFv3 transported over IPv4, 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 having its OSPF version field
+   set to 3.
+
+   An OSPFv3 packet followed by an OSPF link-local signaling (LLS)
+   extension data block [RFC5613] encapsulated in an IPv4 packet is
+   illustrated in Figure 2.
+
+   Since an IPv4 header without options is only 20 octets long and is
+   shorter than an IPv6 header, an OSPFv3 packet encapsulated in a
+   20-octet IPv4 header is shorter than an OSPFv3 packet encapsulated in
+   an IPv6 header.  Consequently, the link MTU for IPv6 is sufficient to
+   transport an OSPFv3 packet encapsulated in a 20-octet IPv4 header.
+   If the link MTU is not sufficient to transport an OSPFv3 packet in
+   IPv4, then OSPFv3 can rely on IP fragmentation and reassembly
+   [RFC791].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 4]
+
+RFC 7949          OSPFv3 over IPv4 for IPv6 Transition       August 2016
+
+
+ 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 ...                        |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+           Note: "IHL" stands for Internet Header Length.
+
+       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
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 5]
+
+RFC 7949          OSPFv3 over IPv4 for IPv6 Transition       August 2016
+
+
+3.1.  Source Address
+
+   For OSPFv3 over IPv4, the source address is the primary IPv4 address
+   for the interface over which the packet is transmitted.  All OSPFv3
+   routers on the link should share the same IPv4 subnet for IPv4
+   transport to function correctly.
+
+   While OSPFv2 operates on a subnet, OSPFv3 operates on a link
+   [RFC5340].  Accordingly, an OSPFv3 router implementation MAY support
+   adjacencies with OSPFv3 neighbors on different IPv4 subnets.  If this
+   is supported, the IPv4 data plane MUST resolve IPv4 addresses to
+   Layer 2 addresses using ARP on multi-access networks and point-to-
+   point over LAN [RFC5309] for direct next hops on different IPv4
+   subnets.  When OSPFv3 adjacencies on different IPv4 subnets are
+   supported, Bidirectional Forwarding Detection (BFD) [RFC5881] cannot
+   be used for adjacency loss detection since BFD is restricted to a
+   single subnet.
+
+3.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 an OSPFv2 neighbor.  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 multi-access networks.
+
+   Thus, for an OSPFv3-over-IPv4 packet to be sent to AllSPFRouters, the
+   destination address field in the IPv4 packet MUST be 224.0.0.5.  For
+   an OSPFv3-over-IPv4 packet to be sent to AllDRouters, the destination
+   address field in the IPv4 packet MUST 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
+   transported in an IPv4 packet would specify the OSPFv3 neighbor's
+   IPv4 address as the destination address.
+
+3.3.  OSPFv3 Header Checksum
+
+   For IPv4 transport, the pseudo-header used in the checksum
+   calculation will contain the IPv4 source and destination addresses,
+   the OSPFv3 protocol ID, and the OSPFv3 length from the OSPFv3 header
+   (Appendix A.3.1 of [RFC5340]).  The format is similar to the UDP
+   pseudo-header as described in [RFC768] and is illustrated in
+   Figure 3.
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 6]
+
+RFC 7949          OSPFv3 over IPv4 for IPv6 Transition       August 2016
+
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Source Address                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Destination Address                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     0         | Protocol (89) |     OSPFv3 Packet Length      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 3: Pseudo-header for OSPFv3 over IPv4
+
+3.4.  Operation over Virtual Links
+
+   When an OSPF router sends an OSPF packet over a virtual link, the
+   receiving router might not be directly connected to the sending
+   router.  Thus, the destination IP address of the IP packet must be a
+   reachable unicast IP address for the virtual link endpoint.  Because
+   IPv6 is the presumed Internet protocol and an IPv4 destination is not
+   routable, the OSPFv3 address family extension [RFC5838] specifies
+   that only virtual links in the IPv6 address family are supported.
+
+   As illustrated in Figure 1, this document specifies OSPFv3 transport
+   over IPv4.  As a result, OSPFv3 virtual links can be supported with
+   IPv4 address families by simply setting the IPv4 destination address
+   to a reachable IPv4 unicast address for the virtual link endpoint.
+   Hence, the restriction in Section 2.8 of RFC 5838 [RFC5838] is
+   relaxed since virtual links can now be supported for IPv4 address
+   families as long as the transport is also IPv4.  If IPv4 transport,
+   as specified herein, is used for IPv6 address families, virtual links
+   cannot be supported. Hence, in OSPF routing domains that require
+   virtual links, the IP transport MUST match the address family (IPv4
+   or IPv6).
+
+4.  Management Considerations
+
+4.1.  Coexistence with OSPFv2
+
+   Since OSPFv2 [RFC2328] and OSPFv3 over IPv4 as described herein use
+   exactly the same protocol and IPv4 addresses, OSPFv2 packets may be
+   delivered to the OSPFv3 process and vice versa.  When this occurs,
+   the mismatched protocol packets will be dropped due to validation of
+   the version in the first octet of the OSPFv2/OSPFv3 protocol header.
+   Note that this will not prevent the packets from being delivered to
+   the correct protocol process as standard socket implementations will
+   deliver a copy to each socket matching the selectors.
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 7]
+
+RFC 7949          OSPFv3 over IPv4 for IPv6 Transition       August 2016
+
+
+   Implementations of OSPFv3 over IPv4 transport SHOULD implement
+   separate counters for a protocol mismatch and SHOULD provide means to
+   suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket SNMP
+   notifications as described in [RFC4750] and the ospfv3IfRxBadPacket
+   and ospv3VirtIfRxBadPacket SNMP notifications as described in
+   [RFC5643] when an OSPFv2 packet is received by the OSPFv3 process or
+   vice versa.
+
+5.  Security Considerations
+
+   OSPFv3 [RFC5340] relies on IPsec [RFC4301] for authentication and
+   confidentiality.  "Authentication/Confidentiality in OSPFv3"
+   [RFC4552] specifies how IPsec is used with OSPFv3 over IPv6
+   transport.  In order to use OSPFv3 with IPv4 transport as specified
+   herein, further work such as "Authentication/Confidentiality in
+   OSPFv2" [IPsec-OSPF] would be required.
+
+   An optional OSPFv3 Authentication Trailer [RFC7166] 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 as described herein, the IPv4 source
+   address should be placed in the first 4 octets of Apad followed by
+   the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times, where L is
+   the length of the hash measured in octets.
+
+   The processing of the optional Authentication Trailer is contained
+   entirely within the OSPFv3 protocol.  In other words, each OSPFv3
+   router instance is responsible for the authentication, without
+   involvement from IPsec or any other IP-layer function.  Consequently,
+   except for calculation of the Apad value, transporting OSPFv3 packets
+   using IPv4 does not change the generation or validation of the
+   optional OSPFv3 Authentication Trailer.
+
+6.  References
+
+6.1.   Normative References
+
+   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
+              DOI 10.17487/RFC0791, September 1981,
+              <http://www.rfc-editor.org/info/rfc791>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 8]
+
+RFC 7949          OSPFv3 over IPv4 for IPv6 Transition       August 2016
+
+
+   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
+              DOI 10.17487/RFC2328, April 1998,
+              <http://www.rfc-editor.org/info/rfc2328>.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+              December 1998, <http://www.rfc-editor.org/info/rfc2460>.
+
+   [RFC5309]  Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point
+              Operation over LAN in Link State Routing Protocols",
+              RFC 5309, DOI 10.17487/RFC5309, October 2008,
+              <http://www.rfc-editor.org/info/rfc5309>.
+
+   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
+              <http://www.rfc-editor.org/info/rfc5340>.
+
+   [RFC5838]  Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
+              R. Aggarwal, "Support of Address Families in OSPFv3",
+              RFC 5838, DOI 10.17487/RFC5838, April 2010,
+              <http://www.rfc-editor.org/info/rfc5838>.
+
+6.2.  Informative References
+
+   [IPsec-OSPF]
+              Gupta, M. and N. Melam, "Authentication/Confidentiality
+              for OSPFv2", Work in Progress, draft-gupta-ospf-
+              ospfv2-sec-01, August 2009.
+
+   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              DOI 10.17487/RFC0768, August 1980,
+              <http://www.rfc-editor.org/info/rfc768>.
+
+   [RFC826]   Plummer, D., "Ethernet Address Resolution Protocol: Or
+              Converting Network Protocol Addresses to 48.bit Ethernet
+              Address for Transmission on Ethernet Hardware", STD 37,
+              RFC 826, DOI 10.17487/RFC0826, November 1982,
+              <http://www.rfc-editor.org/info/rfc826>.
+
+   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
+              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
+              <http://www.rfc-editor.org/info/rfc2464>.
+
+   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+              DOI 10.17487/RFC4271, January 2006,
+              <http://www.rfc-editor.org/info/rfc4271>.
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 9]
+
+RFC 7949          OSPFv3 over IPv4 for IPv6 Transition       August 2016
+
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
+              December 2005, <http://www.rfc-editor.org/info/rfc4301>.
+
+   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
+              for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
+              <http://www.rfc-editor.org/info/rfc4552>.
+
+   [RFC4750]  Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed.,
+              Coltun, R., and F. Baker, "OSPF Version 2 Management
+              Information Base", RFC 4750, DOI 10.17487/RFC4750,
+              December 2006, <http://www.rfc-editor.org/info/rfc4750>.
+
+   [RFC5613]  Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
+              Yeung, "OSPF Link-Local Signaling", RFC 5613,
+              DOI 10.17487/RFC5613, August 2009,
+              <http://www.rfc-editor.org/info/rfc5613>.
+
+   [RFC5643]  Joyal, D., Ed., and V. Manral, Ed., "Management
+              Information Base for OSPFv3", RFC 5643,
+              DOI 10.17487/RFC5643, August 2009,
+              <http://www.rfc-editor.org/info/rfc5643>.
+
+   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
+              DOI 10.17487/RFC5881, June 2010,
+              <http://www.rfc-editor.org/info/rfc5881>.
+
+   [RFC7166]  Bhatia, M., Manral, V., and A. Lindem, "Supporting
+              Authentication Trailer for OSPFv3", RFC 7166,
+              DOI 10.17487/RFC7166, March 2014,
+              <http://www.rfc-editor.org/info/rfc7166>.
+
+Acknowledgments
+
+   The authors would like to thank Alexander Okonnikov for his thorough
+   review and valuable feedback and Suresh Krishnan for pointing out
+   that clear specification for the pseudo-header used in the OSPFv3
+   packet checksum calculation was required.  The authors would also
+   like to thank Wenhu Lu for acting as document shepherd.
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 10]
+
+RFC 7949          OSPFv3 over IPv4 for IPv6 Transition       August 2016
+
+
+Authors' Addresses
+
+   Ing-Wher Chen
+   Ericsson
+
+   Email: ichen@kuatrotech.com
+
+
+   Acee Lindem
+   Cisco
+
+   Email: acee@cisco.com
+
+
+   RJ Atkinson
+   Consultant
+
+   Email: rja.lists@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 11]
+