Network Working Group Sina Mirtorabi Internet Draft Abhay Roy Document: draft-mirtorabi-ospfv3-multicast-af-00.txt Cisco Systems Expiration Date: December 2003 June 2003 IPv6 Multicast address-family in OSPFv3 draft-mirtorabi-ospfv3-multicast-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 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. Abstract This document describes IPv6 multicast address-family support in OSPFv3. There is no additional LSA introduced to the existing LSA defined for IPv6 unicast address-family to carry prefixes. A new bit is defined in the Prefix Options field in order to include a prefix in IPv6 multicast address-family. 1. Introduction [Ref1] introduces support of address-family in OSPFv3 [Ref2] by defining an AddressFamilies field in Router-LSA. This allows to use the existing Router-LSA and Network-LSA for different address-families and not introduce any new LSA for announcing the topology of an address-family. Therefore support of the generic address-family document as defined in [Ref1] is a pre-requisite for support of IPv6 multicast address-family defined in this document. This document does not introduce any new LSAs. Any prefixes that belong to IPv6 multicast address-family can be carried in the existing LSAs defined in OSPFv3 [Ref2] as specified in the following sections. Mirtorabi, Roy [Page 1] Internet Draft IPv6 Multicast AF in OSPFv3 June 2003 2. IPv6 multicast address-family bit We define a new bit in the Options field in order to include or exclude a node in IPv6 multicast address-family. When a router participates in IPv6 multicast address-family, it MUST set this bit. This bit has the same function as V6 bit [Ref2]. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+--+--+--+--+--+--+--+ | | | | | | | | | | | | | | | |mV6|AF|DC| R| N|MC| E|V6| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+--+--+--+--+--+--+--+ mV6-bit If this bit is clear, the node (all links) should be excluded from IPv6 multicast address-family routing calculation. Note that when mV6-AF bit is set for a link, in the AddressFamilies field [Ref1], mV6 bit in the Options field MUST be set. In other words if any link participates in IPv6 multicast address-family, the node MUST participate in IPV6 multicast address-family. 3. Carrying IPv6 prefixes for IPv6 multicast address-family Each prefix in unicast IPv6 address-family defined in OSPFv3, is advertised along with a Prefix Options field that serves as input to the various routing calculations. IPv6 prefixes belonging to IPv6 multicast address-family can use the same LSA defined in OSPFv3 by simply defining a new bit in the Prefix Options field. 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | | | |M6| P|MC|LA|NU| +--+--+--+--+--+--+--+--+ The Prefix Options field M6 bit: IPv6 Multicast address-family bit. If a prefix belong to IPv6 multicast AF, this bit MUST bit set, otherwise it MUST be cleared. A router that does not understand M6 bit will ignore this bit and may install the prefix for IPv6 unicast address-family, in order to avoid that the following rule is established: o If a prefix is only advertised in IPv6 unicast address-family, M6 and NU bit MUST be cleared Mirtorabi, Roy [Page 2] Internet Draft IPv6 Multicast AF in OSPFv3 June 2003 o If a prefix is only advertised in IPv6 multicast address-family, M6 and NU bit MUST be set o If a prefix is advertised in both IPv6 unicast and multicast address-families, M6 bit MUST be set and NU bit MUST be cleared AF / bits | NU | M6 -------------------------|------|------ IPv6 unicast | 0 | 0 IPv6 unicast & multicast | 0 | 1 IPv6 multicast | 1 | 1 By setting the NU bit when the prefix does not belong to IPv6 unicast address-family, we ensure that the prefix will not be installed in IPv6 unicast address-family RIB. When the prefix applies to both IPv6 unicast and multicast address-families (NU bit cleared and M6 bit set) and the other option bits are not the same between the two address-families (for example P bit set applies only to one address-family) the prefix is simply replicated once as IPv6 unicast and once as IPv6 multicast with the corresponding options. In other word when a prefix is advertised in both address-families the other option bits apply to both address-families, if they don't one need to advertise them separately in each address-family. 4. LSA Generator (LG) for multi-access links In IPv6 unicast address-family, Designated Router (DR) of a multi-access link is in charge of generating intra-area-prefix-LSA for all the fully adjacent routers on that link. This is done by copying the list of prefixes in the Link-LSA into its intra-area-prefix-LSA. However in doing so prefixes having the NU-bit and/or LA-bit set in their Options field are not copied nor link-local addresses are copied. Since DR may not be IPv6 multicast AF aware, a router called LG [Ref1] will be in charge of generating prefixes belonging to IPv6 multicast AF for the multi-access link. A router MUST NOT flush its intra-area-prefix-lsa referencing a router-LSA before the WaitTimer (after InterfaceUp state). This will assure a minimum gap between intra-area-prefix-lsa referencing a network-LSA and flushing of intra-area-prefix-lsa referencing a router-LSA. 5. SPF computation for IPv6 multicast address-family SPF computation is performed as defined in [Ref1], i.e. by considering AddressFamilies field in the Router-LSA link descriptions and including only link that have the mV6-AF bit set. Mirtorabi, Roy [Page 3] Internet Draft IPv6 Multicast AF in OSPFv3 June 2003 Further if the mV6 bit is clear in the Options field, the node should be excluded from IPv6 multicast address-family topology. The result of this computation MUST be kept in a separate RIB that belongs to IPv6 multicast address-family. A separate RIB also is maintained for Router Routing table in order to keep the paths to ABR's and ASBR's belonging to IPv6 multicast address-family. This is done by considering AF-Functionality-LSA defined in [Ref1]. 6. Routing table calculation for IPv6 multicast address-family The IPv6 multicast address-family routing calculation proceeds along the same lines as the IPv6 unicast address-family routing calculation defined in section 3.8 of [Ref2]. Differences between the IPv6 unicast and multicast address-family calculations include: o AF-Functionality-LSA [Ref1] is considered while populating Router Routing table. o AF-Inter-Area-Router-LSAs [Ref1] are considered while calculating inter-area routes. o A prefix is considered for IPv6 multicast routing calculation only if it has the M6 bit set in the Prefix Options field. 7. Compatibility issues Interoperability between AF capable and non-AF capable routers is detailed in [Ref1]. This document does not introduce any new compatibility issues with [Ref1] or [Ref2]. 8. Security Considerations The technique described in this document does not introduce any new security issues to the OSPFv3 protocol. 9. References [Ref1] Mirtorabi, Barnes, Roy, "Support of address-family in OSPFv3", draft-ietf-mirtorabi-ospfv3-af-01.txt, Work in progress. [Ref2] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. Mirtorabi, Roy [Page 4] Internet Draft IPv6 Multicast AF in OSPFv3 June 2003 10. Authors' address Sina Mirtorabi Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA E-mail: sina@cisco.com Abhay Roy Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA E-mail: akr@cisco.com Mirtorabi, Roy [Page 5]