diff options
Diffstat (limited to 'doc/rfc/rfc5838.txt')
| -rw-r--r-- | doc/rfc/rfc5838.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc5838.txt b/doc/rfc/rfc5838.txt new file mode 100644 index 0000000..49df637 --- /dev/null +++ b/doc/rfc/rfc5838.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Lindem, Ed. +Request for Comments: 5838 Ericsson +Category: Standards Track S. Mirtorabi +ISSN: 2070-1721 A. Roy + M. Barnes + Cisco Systems + R. Aggarwal + Juniper Networks + April 2010 + + Support of Address Families in OSPFv3 + +Abstract + + This document describes a mechanism for supporting multiple address + families (AFs) in OSPFv3 using multiple instances. It maps an AF to + an OSPFv3 instance using the Instance ID field in the OSPFv3 packet + header. This approach is fairly simple and minimizes extensions to + OSPFv3 for supporting multiple AFs. + +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/rfc5838. + +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. + + + +Lindem, et al. Standards Track [Page 1] + +RFC 5838 OSPFv3 AF April 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Design Considerations . . . . . . . . . . . . . . . . . . 2 + 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 3 + 2. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Instance ID Values for New AFs . . . . . . . . . . . . . . 3 + 2.2. OSPFv3 Options Changes . . . . . . . . . . . . . . . . . . 4 + 2.3. Advertising Prefixes in AFs Other Than IPv6 . . . . . . . 4 + 2.4. Changes to the Hello Packet Processing . . . . . . . . . . 4 + 2.5. Next-Hop Calculation for IPv4 Unicast and Multicast AFs . 5 + 2.6. AS-External-LSA and NSSA-LSA Forwarding Address for + IPv4 Unicast and IPv4 Multicast AFs . . . . . . . . . . . 5 + 2.7. Database Description Maximum Transmission Unit (MTU) + Specification for Non-IPv6 AFs . . . . . . . . . . . . . . 6 + 2.8. Operation over Virtual Links . . . . . . . . . . . . . . . 8 + 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 + +1. Introduction + + OSPFv3 [OSPFV3] has been defined to support the base IPv6 unicast + address family (AF). There are requirements to advertise other AFs + in OSPFv3, including multicast IPv6, unicast IPv4, and multicast + IPv4. This document supports these other AFs in OSPFv3 by mapping + each AF to a separate Instance ID and OSPFv3 instance. + +1.1. Design Considerations + + This section describes the rationale for using the multiple Instance + ID approach to support multiple address families in OSPFv3. As + described earlier, OSPFv3 is designed to support multiple instances. + Hence, mapping an instance to an address family doesn't introduce any + new mechanisms to the protocol. It minimizes the protocol extensions + required, and it simplifies the implementation. The presence of a + separate link state database per address family is also easier to + debug and operate. Additionally, it doesn't change the existing + instance, area, and interface-based configuration model in most + OSPFv3 implementations. + + + + + + + +Lindem, et al. Standards Track [Page 2] + +RFC 5838 OSPFv3 AF April 2010 + + +1.2. Requirements Notation + + 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-KEYWORDS]. + +2. Protocol Details + + Currently, the entire Instance ID number space is used for IPv6 + unicast. This specification assigns different Instance ID ranges to + different AFs in order to support other AFs in OSPFv3. Each Instance + ID implies a separate OSPFv3 instance with its own neighbor + adjacencies, link state database, protocol data structures, and + shortest path first (SPF) computation. + + Additionally, the current Link State Advertisements (LSAs) defined to + advertise IPv6 unicast prefixes can be used to advertise prefixes + from other AFs without modification. + + It should be noted that OSPFv3 runs on top of IPv6 and uses IPv6 link + local addresses for OSPFv3 control packets. Therefore, it is + required that IPv6 be enabled on an OSPFv3 link, although the link + may not be participating in any IPv6 AFs. + +2.1. Instance ID Values for New AFs + + Instance ID zero is already defined by default for the IPv6 unicast + AF. When this specification is used to support multiple AFs, we + define the following ranges for different AFs. The first value of + each range is the default value for the corresponding AF. + + Instance ID # 0 - # 31 IPv6 unicast AF + Instance ID # 32 - # 63 IPv6 multicast AF + Instance ID # 64 - # 95 IPv4 unicast AF + Instance ID # 96 - # 127 IPv4 multicast AF + Instance ID # 128 - # 255 Unassigned + + OSPFv3 Instance IDs + + + + + + + + + + + + + +Lindem, et al. Standards Track [Page 3] + +RFC 5838 OSPFv3 AF April 2010 + + +2.2. OSPFv3 Options Changes + + A new AF-bit is added to the OSPFv3 Options field. The V6-bit is + only applicable to the IPv6 unicast AF. + + 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+-+-+--+ + | | | | | | | | | | | | | | | |AF|*|*|DC|R|N|x|E|V6| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+-+-+--+ + + The Options field + + OSPFv3 Options + + V6-bit + The V6-bit is used in OSPFv3 to exclude a node from IPv6 unicast + route calculation but allow it in the SPF calculation for other + address families. Since the Instance ID now denotes the AF + explicitly, this bit is ignored in AFs other than IPv6 unicast. + + AF-bit + When an OSPFv3 router is supporting AFs as described in this + specification, it MUST set the AF-bit in the OSPFv3 Options field + of Hello packets, Database Description packets, and LSAs. + +2.3. Advertising Prefixes in AFs Other Than IPv6 + + Each prefix advertised in OSPFv3 has a prefix Length field [OSPFV3]. + This facilitates advertising prefixes of different lengths in + different AFs. The existing LSAs defined in OSPFv3 are used for this + and there is no need to define new LSAs. + + Prefixes that don't conform to the AF of an OSPFv3 instance MUST NOT + be used in the route computation for that instance. + +2.4. Changes to the Hello Packet Processing + + When an OSPFv3 router does not support this specification and it is + configured with the corresponding Instance ID, packets could be black + holed. This could happen due to misconfiguration or a router + software downgrade. Black holing is possible because a router that + doesn't support this specification can still be included in the SPF + calculated path as long as it establishes adjacencies using the + Instance ID corresponding to the AF. Note that Router-LSAs and + Network-LSAs are AF independent. + + + + + +Lindem, et al. Standards Track [Page 4] + +RFC 5838 OSPFv3 AF April 2010 + + + In order to avoid the above situation, Hello packet processing is + changed in order to only establish adjacencies with routers that have + the AF-bit set in their Options field. + + Receiving Hello packets is specified in section 4.2.2.1 of [OSPFV3]. + The following check is added to Hello packet reception: + + o When an OSPFv3 router participates in an AF (sets the AF-bit in + the Options field), it MUST discard Hello packets having the AF- + bit clear in the Options field. The only exception is the Base + IPv6 unicast AF, where this check MUST NOT be done (for backward + compatibility). + +2.5. Next-Hop Calculation for IPv4 Unicast and Multicast AFs + + OSPFv3 runs on top of IPv6 and uses IPv6 link local addresses for + OSPFv3 control packets and next-hop calculations. Although IPv6 link + local addresses could be used as next hops for IPv4 address families, + it is desirable to have IPv4 next-hop addresses. For example, in the + IPv4 multicast AF, the Protocol Independent Multicast (PIM) [PIM] + neighbor address and the next-hop address should both be IPv4 + addresses in order for the Reverse Path Forwarding (RPF) lookup to + work correctly. Troubleshooting is also easier when the prefix + address and next-hop address are in the same AF. + + In order to achieve this, the link's IPv4 address will be advertised + in the "link local address" field of the IPv4 instance's Link-LSA. + This address is placed in the first 32 bits of the "link local + address" field and is used for IPv4 next-hop calculations. The + remaining bits MUST be set to zero. + + We denote a Direct Interface Address (DIA) as an IPv4 or IPv6 address + that is both directly reachable via an attached link and has an + available layer 3 to layer 2 mapping. Note that there is no explicit + need for the IPv4 link addresses to be on the same subnet. An + implementation SHOULD resolve layer 3 to layer 2 mappings via the + Address Resolution Protocol (ARP) [ARP] or Neighbor Discovery (ND) + [ND] for a DIA even if the IPv4 address is not on the same subnet as + the router's interface IP address. + +2.6. AS-External-LSA and NSSA-LSA Forwarding Address for IPv4 Unicast + and IPv4 Multicast AFs + + For OSPFv3, this address is an IPv6 host address (128 bits). If + included, data traffic for the advertised destination will be + forwarded to this address. For IPv4 unicast and IPv4 multicast AFs, + the Forwarding Address in AS-external-LSAs and NSSA-LSAs MUST encode + an IPv4 address. To achieve this, the IPv4 Forwarding Address is + + + +Lindem, et al. Standards Track [Page 5] + +RFC 5838 OSPFv3 AF April 2010 + + + advertised by placing it in the first 32 bits of the Forwarding + Address field in AS-external-LSAs and NSSA-LSAs. The remaining bits + MUST be set to zero. + +2.7. Database Description Maximum Transmission Unit (MTU) Specification + for Non-IPv6 AFs + + For address families other than IPv6, both the MTU for the instance + address family and the IPv6 MTU used for OSPFv3 maximum packet + determination MUST be considered. The MTU in the Database + Description packet MUST always contain the MTU corresponding to the + advertised address family. For example, if the instance corresponds + to an IPv4 address family, the IPv4 MTU for the interface MUST be + specified in the interface MTU field. As specified in Section 10.6 + of [OSPFV2], the Database Description packet will be rejected if the + MTU is greater than the receiving interface's MTU for the address + family corresponding to the instance. This behavior will assure that + an adjacency is not formed and address family specific routes are not + installed over a path with conflicting MTUs. + + The value used for OSPFv3 maximum packet size determination MUST also + be compatible for an adjacency to be established. Since only a + single MTU field is specified, the M6-bit is defined by this + specification. If the M6-bit is clear, the specified MTU SHOULD also + be checked against the IPv6 MTU, and the Database Description packet + SHOULD be rejected if the MTU is larger than the receiving + interface's IPv6 MTU. An OSPFv3 router SHOULD NOT set the M6-bit if + its IPv6 MTU and address family specific MTU are the same. + + If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 + address families. If the M6-bit is set, the IPv6 MTU is dictated by + the presence or absence of an IPv6 MTU TLV in the link-local + signaling (LLS) [LLS] block. If this TLV is present, it carries the + IPv6 MTU that SHOULD be compared with the local IPv6 MTU. If this + TLV is absent, the minimum IPv6 MTU of 1280 octets SHOULD be used for + the comparison (refer to [IPV6]). + + If the M6-bit is set in a received Database Description packet for a + non-IPv6 address family, the receiving router MUST NOT check the + Interface MTU in the Database Description packet against the + receiving interface's IPv6 MTU. + + + + + + + + + + +Lindem, et al. Standards Track [Page 6] + +RFC 5838 OSPFv3 AF April 2010 + + + The figure below graphically depicts the changed fields in octets + 20-23 of the OSPFv3 Database Description packet: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ + | Interface MTU | 0 |0|0|0|M6|0|I|M|MS| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ + + OSPFv3 Database Description Packet Changes + + The changed fields in the Database Description packet are described + below. The remaining fields are unchanged from [OSPFV3]. + + Interface MTU + The size in octets of the largest address family specific datagram + that can be sent on the associated interface without + fragmentation. The MTUs of common Internet link types can be + found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set + to 0 in Database Description packets sent over virtual links. + + M6-bit + The IPv6 MTU bit - this bit indicates that the sender is using a + different IPv6 MTU than the MTU for the AF. + + An IPv6 MTU TLV can be optionally carried in an LLS block as + described above. This TLV carries the IPv6 MTU for the interface. + The length field of the TLV is set to 4 bytes. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 17 | 4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 MTU | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Format of IPv6 MTU TLV + + Only one instance of the IPv6 MTU TLV MAY appear in the LLS block. + Instances subsequent to the first are not processed, and the LLS + inconsistency SHOULD be logged. + + + + + + + + + +Lindem, et al. Standards Track [Page 7] + +RFC 5838 OSPFv3 AF April 2010 + + +2.8. Operation over Virtual Links + + OSPFv3 control packets sent over a virtual link are IPv6 packets and + may traverse multiple hops. Therefore, there MUST be a global IPv6 + address associated with the virtual link so that OSPFv3 control + packets are forwarded correctly by the intermediate hops between + virtual link endpoints. Although this requirement can be satisfied + in IPv6 unicast AFs, it will not function in other AFs as there will + not be a routable global IPv6 address or forwarding path. Therefore, + virtual links are not supported in AFs other than IPv6 unicast. + +3. Backward Compatibility + + All modifications to OSPFv3 apply exclusively to the support of + address families other than the IPv6 unicast AF using multiple OSPFv3 + instances as described in this specification. These modifications + are not applicable to IPv6 unicast topologies and do not preclude + future single instance mechanisms for supporting multiple address + families. + + In this section, we will define a non-capable OSPFv3 router as one + not supporting this specification. When multiple AFs are supported + as defined herein, each new AF will have a corresponding Instance ID + and can interoperate with the existing non-capable OSPFv3 routers in + an IPv6 unicast topology. Furthermore, when a non-capable OSPFv3 + router uses an Instance ID that is reserved for a given AF, no + adjacency will be formed with this router since the AF-bit in the + Options field will be clear in its OSPFv3 Hello packets. Therefore, + there are no backward compatibility issues. AFs can be gradually + deployed without disturbing OSPFv3 routing domains with non-capable + OSPFv3 routers. + +4. Security Considerations + + IPsec [IPsec] can be used for OSPFv3 authentication and + confidentiality as described in [OSPFV3-AUTH]. When multiple OSPFv3 + instances use the same interface, they all MUST use the same Security + Association (SA), since the SA selectors do not provide selection + based on data in OSPFv3 Header fields (e.g., the Instance ID). This + restriction is documented in Section 8 of [OSPFV3-AUTH]. + + Security considerations for OSPFv3 are covered in [OSPFV3]. + + + + + + + + + +Lindem, et al. Standards Track [Page 8] + +RFC 5838 OSPFv3 AF April 2010 + + +5. IANA Considerations + + The following IANA assignments were made from existing registries. + + o The AF-bit was assigned from the OSPFv3 Options registry as + defined in Section 2.2. + + o The M6-bit was assigned from the DD Packet Flags registry as + defined in Section 2.7 + + o The TLV type (17) for the IPv6 MTU TLV was assigned from the OSPF + LLS TLVs registry. + + IANA created a new registry, "OSPFv3 Instance ID Address Family + Values", for assignment of the mapping of OSPFv3 Instance IDs to + address families when this specification is used to support multiple + address families. Note that the Instance ID field MAY be used for + applications other than the support of multiple address families. + However, if it is being used for address families as described in + this specification, the assignments herein SHOULD be honored. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lindem, et al. Standards Track [Page 9] + +RFC 5838 OSPFv3 AF April 2010 + + + +-------------+----------------------+--------------------+ + | Value/Range | Designation | Assignment Policy | + +-------------+----------------------+--------------------+ + | 0 | Base IPv6 Unicast AF | Already assigned | + | | | | + | 1-31 | IPv6 Unicast AFs | Already assigned | + | | dependent on local | | + | | policy | | + | | | | + | 32 | Base IPv6 Multicast | Already assigned | + | | | | + | 33-63 | IPv6 Multicast AFs | Already assigned | + | | dependent on local | | + | | policy | | + | | | | + | 64 | Base IPv4 Unicast AF | Already assigned | + | | | | + | 65-95 | IPv4 Unicast AFs | Already assigned | + | | dependent on local | | + | | policy | | + | | | | + | 96 | Base IPv4 Multicast | Already assigned | + | | | | + | 97-127 | IPv4 Multicast AFs | Already assigned | + | | dependent on local | | + | | policy | | + | | | | + | 128-255 | Unassigned | Standards Action | + +-------------+----------------------+--------------------+ + + OSPFv3 Address Family Use of Instance IDs + + o Instance IDs 0-127 are assigned by this specification. + + o Instance IDs in the range 128-255 are not assigned at this time. + Before any assignments can be made in this range, there MUST be a + Standards Track RFC including an IANA Considerations section + explicitly specifying the AF Instance IDs being assigned. + + + + + + + + + + + + + +Lindem, et al. Standards Track [Page 10] + +RFC 5838 OSPFv3 AF April 2010 + + +6. References + +6.1. Normative References + + [IPV6] Deering, S. and R. Hinden, "Internet Protocol, + Version 6 (IPv6) Specification", RFC 2460, + December 1998. + + [IPsec] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, + April 1998. + + [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, + "OSPF for IPv6", RFC 5340, July 2008. + + [OSPFV3-AUTH] Gupta, M. and S. Melam, "Authentication/ + Confidentiality for OSPFv3", RFC 4552, June 2006. + + [RFC-KEYWORDS] Bradner, S., "Key words for use in RFC's to Indicate + Requirement Levels", RFC 2119, March 1997. + +6.2. Informative References + + [ARP] 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, November 1982. + + [LLS] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. + Young, "OSPF Link-Local Signaling", RFC 5613, + August 2009. + + [MTUDISC] Mogul, J. and S. Deering, "Path MTU Discovery", + RFC 1191, November 1990. + + [ND] Narten, T., Nordmark, E., Simpson, W., and H. + Soliman, "Neighbor Discovery for IP version 6 + (IPv6)", RFC 4861, September 2007. + + [PIM] Fenner, B., Handley, M., Holbrook, H., and I. + Kouvelas, "Protocol Independent Multicast - Sparse + Mode (PIM-SM): Protocol Specification (Revised)", + RFC 4601, August 2006. + + + + + + +Lindem, et al. Standards Track [Page 11] + +RFC 5838 OSPFv3 AF April 2010 + + +Appendix A. Acknowledgments + + The RFC text was produced using Marshall Rose's xml2rfc tool. + + Thanks to Tom Henderson and the folks at Boeing for implementing this + document in the Quagga routing suite, http:www.quagga.net. + + Thanks to Nischal Sheth for review and comments. + + Thanks to Christian Vogt for comments during the Gen-ART review. + + Thanks to Adrian Farrel for comments during the IESG review. + + Thanks to Alfred Hoenes for comments during the editing process. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lindem, et al. Standards Track [Page 12] + +RFC 5838 OSPFv3 AF April 2010 + + +Authors' Addresses + + Acee Lindem (editor) + Ericsson + 102 Carric Bend Court + Cary, NC 27519 + USA + + EMail: acee.lindem@ericsson.com + + + Sina Mirtorabi + Cisco Systems + 3 West Plumeria Drive + San Jose, CA 95134 + USA + + EMail: smirtora@cisco.com + + + Abhay Roy + Cisco Systems + 225 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: akr@cisco.com + + + Michael Barnes + Cisco Systems + 225 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: mjbarnes@cisco.com + + + Rahul Aggarwal + Juniper Networks + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089 + USA + + EMail: rahul@juniper.net + + + + + + +Lindem, et al. Standards Track [Page 13] + |