Network Working Group Sina Mirtorabi Internet Draft Michael Barnes Document: draft-mirtorabi-ospfv3-af-00.txt Abhay Roy Expiration Date: August 2003 Cisco Systems February 2003 Support of address families in OSPFv3 draft-mirtorabi-ospfv3-af-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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. Abstract This document describes an extensible mechanism to support Address Families in OSPFv3. One undefined field in the Router-LSA is used to define the address-families on a link. A router may participate in multiple address families on different links. This information needs to be advertised so that only applicable link are used in the SPF calculation when building an address family specific shortest path tree. 1. Motivation OSPFv3 has been defined with a network protocol independent core. It's accomplished by Router-LSA and Network-LSA conveying only topology information. There is also an implicit support for IPv6 address-family by using V6 bit in Options field. Mirtorabi, Barnes, Roy [Page 1] Internet Draft AF in OSPFv3 February 2003 When a router supports different address-families, some of the links may participate in only a subset of the address-families. So there is a need to explicitly include or exclude links that participate in a given address-family. This is needed in order to compute the shortest path tree correctly. Otherwise packets will be dropped by routers which are not participating in the address-family. Example of other address-families could be IPv6 Multicast, IPv4 Unicast, IPv4 Multicast etc. 2. Address Family capability option A new bit is defined in the Options field for address-family support. 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|MC| E|V6| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+ AF-bit If this bit is set, it indicates that the router supports Address Families as defined in this draft. When a router supports address-family it MUST set the AF-bit in the Options field of Hello Packets, DD packets and LSAs. 3. Proposed Solution We define an AddressFamilies (AF) field in the Router-LSA. This field is currently set to Zero [Ref1] and ignored in reception. Each bit in the AF field corresponds to an address-family. When a link participates in a given AF the corresponding bit MUST be set, otherwise it MUST be cleared. Mirtorabi, Barnes, Roy [Page 2] Internet Draft AF in OSPFv3 February 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |0|0|1| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |W|V|E|B| Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |AddressFamilies| Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |AddressFamilies| Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. AddressFamilies field This document only defines the IPv6 address-family. Additional address-families will define and use one of the bits in this field. +--+--+--+--+--+--+--+-----+ | | | | | | | |V6-AF| +--+--+--+--+--+--+--+-----+ V6-AF bit: Unicast IPv6 address-family. If the interface participates in IPv6 address-family this bit MUST be set. Otherwise it MUST be cleared. Note 1: A link participating in multiple address-families will set all of the corresponding AF bits. Mirtorabi, Barnes, Roy [Page 3] Internet Draft AF in OSPFv3 February 2003 Note 2: OSPFv3 [Ref1] defines a V6 bit in the Options field. This bit is used in order to include or exclude a node (all links) in the IPv6 address-family. The V6-AF bit defined in this document (in the AddressFamilies field) is link based. Therefore, when the V6-AF bit is set to include some links in the IPv6 AF, the V6 bit in the Options field MUST be set too. Note 3: Documents defining other address-families in OSPFv3 must introduce the equivalent of V6 bit in the Option field so that a node can be globally included / excluded in the corresponding topology. 5. Extending router functionality to be address-family aware There is a requirement to have the [Nt|W|V|E|B] octet defined in each address-family. For example a router may be ABR or ASBR for the IPv6 address-family without having the same functionality for another AF. Therefore we define a new LSA type called the AF-Functionality-LSA. AF-Functionality-LSA is not used for IPv6 address-family as Router-LSA already contains this information. This LSA describes a router's functionality in a given address-family. It needs to be flooded within the area, which can be done by setting the Unknown bit (U bit) as described in [Ref1]. LSA function code LS Type Description ---------------------------------------------------- 10 0xA00A AF-Functionality-LSA 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |1|0|1| 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AddressFamilies| 0 | Nt W V E B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AddressFamilies| 0 | Nt W V E B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AddressFamilies| 0 | Nt W V E B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mirtorabi, Barnes, Roy [Page 4] Internet Draft AF in OSPFv3 February 2003 AddressFamilies : This field is defined in section 4 of this document. W,V,E,B : These fields are defined in [Ref1] Nt : This field is defined in [Ref2] All other fields are similar to router-lsa fields as described in [Ref1]. When all the bits are clear for an AF, a Router does not need to generate AF-Functionality-LSA as it is implicitly assumed that those bits are cleared. 6. Participating in an address-family over a multi-access link On a multi-access link the Designated Router (DR) is responsible for flooding and establishing adjacencies with all other routers on the link. It is possible that the DR does not support an AF. However, because OSPFv3 floods unknown LSA types, the DR will flood the LSAs defined for an AF that it doesn't support. Therefore, any router can be the DR regardless of whether or not it supports any particular AF. 7. Interacting with non-AF capable routers Routers that are not AF-capable will clear the V6-AF bit in the Router-LSA therefore an AF-capable router will exclude this router from the IPv6 topology. In order to avoid this problem, we define a new parameter in the area data structure called AFCapability. The AFCapability flag can have two values: Enabled, and Disabled. The flag is set to Disabled when an area data structure is created. If the area's AFCapability flag is set to Disabled, the router: 1) MUST set the AF bit in the Options field. 2) MUST set the V6-AF bit in the Router-LSA links, for all the links which need to participate in IPv6 AF. 3) Ignore the Hello reception as specified in section 8. 4) Ignore the V6-AF bit while doing SPF. If the area's AFCapability flag is set to Enabled, the router: 1) MUST set the AF bit in the Options field. 2) MUST set the V6-AF bit in the Router-LSA links, for all the links which need to participate in IPv6 AF. 3) Check the Hello reception as specified in section 8. 4) Check the V6-AF bit while doing SPF, as specified in section 9. Mirtorabi, Barnes, Roy [Page 5] Internet Draft AF in OSPFv3 February 2003 AFCapability can be enabled when all routers in an area are AF capable. Then the V6-AF bit, and any other AddressFamilies bit, will be considered during the SPF. Once all of the routers in an area are AF capable, a non-AF capable router that might join the area would ignore the AddressFamilies bits and treat all links as if they are part of the IPv6 topology. It might then forward IPv6 traffic to an AF-Capable router which has interfaces that are not in the IPv6 AF, and packets would be dropped. In order to avoid this problem, an adjacency will not be formed with a non-AF capable router when the AFCapability flag is set to Enabled, as specified in section 8. 8. Change to the Hello Reception when AFCapability flag is Enabled Receiving Hello Packets is specified in section 3.2.2.1 of [Ref1]. The following check is added to Hello reception: When AFCapability flag is set to Enabled, Hello packets having the AF bit clear in the Option field are discarded. 9. Change to the SPF when AFCapability is Enabled Each address-family may have a different topology, therefore a router may run a different SPF for each address-family. While doing a SPF for an address-family, only links that are part of that address-family (they have the corresponding AF bit set) should be included in the SPF. This will assure that a packet will never be sent to a router that does not support the address-family. 10. Compatibility issues Section 7. details interoperability between AF capable and non-AF capable routers. When AFCapability is Disabled (default mode) there is no interoperability issues. 11. Acknowledgements The authors would like to thank Acee Lindem and Manral Vishwas for their comments on this work. 12. Security Considerations The technique described in this document does not introduce any new security issues to the OSPFv3 protocol. 13. References [Ref1] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. Mirtorabi, Barnes, Roy [Page 6] Internet Draft AF in OSPFv3 February 2003 [Ref2] P. Murphy, "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003. 14. Authors' address Sina Mirtorabi Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA E-mail: sina@cisco.com Michael Barnes Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA E-mail: mjbarnes@cisco.com Abhay Roy Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA E-mail: akr@cisco.com Mirtorabi, Barnes, Roy [Page 7]