INTERNET-DRAFT Jiwoong Lee Expires: May 2002 KTF Advanced Lab Myung-Ki Shin ETRI 8 November 2001 Explicit Multicast over Mobile IP (XMIP) 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 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 obsolete by other documents at anytime. 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. All remarks may be forwarded to author's email address or to Xcast IG(Incubation Group) homepage http://www.xcast-ig.org. Abstract Explicit multicast (Xcast)[1] is a new kind of Internet multicast, in which every packet carries plural unicast addresses of all the destinations within it. Because Xcast does not require membership management and routing information exchange in the intermediate routers, it can effectively provide multicast service to Internet without those overheads. A node mobility supporting protocol, Mobile IP[2,3], requires to be modified to appropriately intercept, Jiwoong Lee Expirre May 2002 [Page 1] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 route and forward Xcast packets. This document specifies the protocol operations for the mobile agent, the mobile node and the correspondent node to support transmission and reception of Xcast datagrams over Mobile IPv4 and Mobile IPv6. Contents Status of This Memo 1 Abstract 1 1. Introduction 3 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview of Xcast over Mobile IP 4 3. Protocol operations over Mobile IPv4 5 3.1. Home agent operations. . . . . . . . . . . . . . . . . . . 6 3.1.1. Requirement for reception. . . . . . . . . . . . . . 6 3.1.2. Home agent specific Xcast routing. . . . . . . . . . 6 3.1.3. Tunneling. . . . . . . . . . . . . . . . . . . . . . 7 3.2. Foreign agent operations. . . . . . . . . . . . . . . . . 7 3.3. Mobile node operations . . . . . . . . . . . . . . . . . . 7 3.3.1. Receiving Xcast packets . . . . . . . . . . . . . . 7 3.3.2. Sending Xcast packets . . . . . . . . . . . . . . . 8 3.3.3. Handling packets with turned on Anonymity bit . . . 8 4. Protocol Operations over Mobile IPv6 8 4.1. Home agent operations. . . . . . . . . . . . . . . . . . . 9 4.1.1. Requirement for link-local scope multicast packet . 9 4.1.2. Home agent specific Xcast routing . . . . . . . . . 9 4.1.3. Tunneling . . . . . . . . . . . . . . . . . . . . . 10 4.2. Mobile node operations . . . . . . . . . . . . . . . . . . 10 4.2.1. Receiving Xcast packets while away from home. . . . 10 4.2.2. Handling packets with turned on Anonymity bit . . . 11 4.2.3. Sending Binding Update. . . . . . . . . . . . . . . 11 4.2.4. Sending Xcast packets while away from home. . . . . 12 4.3. Correspondent node operations. . . . . . . . . . . . . . . 12 4.3.1. Definition of Type MIP Routing header . . . . . . . 12 4.3.2. Binding update in Xcast packets . . . . . . . . . . 13 4.3.3. Sending Xcast packets . . . . . . . . . . . . . . . 13 4.4. Xcast router considerations. . . . . . . . . . . . . . . . 14 4.4.1. Routing packets with Routing extension header . . . 14 4.5. Xcast node considerations. . . . . . . . . . . . . . . . . 14 4.5.1. General Xcast routing requirement . . . . . . . . . 14 5. Security Considerations 15 Jiwoong Lee Expire May 2002 [Page 2] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 Appendix 15 A. Compatibility statements. . . . . . . . . . . . . . . . . . . . 15 B. Xcast header format. . . . . . . . . . . . . . . . . . . .. . . 16 References 17 Author 17 1. Introduction Explicit multicast (Xcast)[1] is a new kind of Internet multicast that has different genealogy from the traditional multicast schemes - the host group model multicast, which is based on RFC 1112[5]. Instead of being addressed to a group-specific multicast address, Xcast packets are addressed to a pre-defined link-local multicast address, named 'All_Xcast_Routers' for hop-by-hop forwarding and carries unicast addresses of destinations within themselves. Since Xcast routing is based neither on multicast address nor pre- established multicast routing table but solely on unicast addresses of destinations, Xcast utilizes the existing unicast routing information and does not require routing/group management information exchange, which are required in the host group model based multicast. As wireless market grows, the mobility of the Internet node is more getting its importance. Mobile IP[2,3] is one emerging technology that supports the Internet node mobility. Mobile IP operations rely on binding of care-of address, intercepting and tunneling of packets. Mobile IP is designed to support unicast, the host group model multicast and, if applied, broadcast, and it currently does not support Explicit multicast. This document is designed for the purpose of seamless support of Xcast over Mobile IP. The mobile agent, the mobile node and the correspondent node require new protocol operations. Some requirements specified in this document update Mobile IP specification[2,3]. Section 2 overviews the protocol including node behavior. Section 3 and section 4 describes the specific protocol operations of the nodes in Mobile IPv4 network and in Mobile IPv6 network respectively. Jiwoong Lee Expire May 2002 [Page 3] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 1.1. Terminology The keywords "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 2119[10]. In addition, this document frequently uses the following terms: Xcast Explicit Multicast. Xcast6 Xcast in IPv6. Mobile IP Mobile IPv4 and/or Mobile IPv6 List of Addresses A field of the Xcast header format carrying the unicast addresses of the recipients Type Xcast Routing extension header A Routing extension header for Xcast6 containing List of Addresses Type MIP Routing extension header A Routing extension header used when a correspondent node directly forwards a packet to a mobile node in Mobile IPv6. Xcast extension information Xcast4 header in IPv4 and Xcast6 header in IPv6. An Xcast6 header consists of a type Xcast Routing extension header and, if any, a type Ports Destination extension header and a Type MIP Routing extension header. Xcast encapsulation Xcast encapsulation within Xcast or Xcast encapsulation within Unicast. This is defined in [9]. The definitions of terms that are not defined here can be found at references at the end. 2. Overview of Xcast over Mobile IP An Xcast-capable home agent receives Xcast packets on behalf of its registered mobile nodes. Since Xcast packets are addressed to a predefined link-local multicast address, the home agent MUST be Jiwoong Lee Expire May 2002 [Page 4] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 able to intercept such packets and tunnel them to the registered mobile nodes. While generic Xcast routers perform their Xcast routing over the addresses shown in List of Addresses field of the Xcast packets, Xcast-capable home agents work in a different manner - in special manner to home agents. The home agent first looks up the care-of addresses bound with the (home) addresses listed in the intercepted Xcast packet. Next it determines the next forwarding hop to each care-of address by using its unicast routing information. The home agent partitions the set of care-of addresses based on the next hops. With this result, the home agent replicates the intercepted Xcast packet and encapsulates them such that - List of Addresses of each tunnel header carries a set of partitioned care-of addresses. - List of Addresses of each inner header carries a set of home addresses which are shown in the original incoming Xcast packet and which are bound with the care-of addresses shown the packet's tunnel header. That is, the home agent performs Xcast-in-Xcast encapsulation [9] based on its mobility binding information. In particular, Xcast over Mobile IPv6 provides to correspondent nodes a way with which they MAY directly forward their Xcast packets to mobile nodes that have sent Binding Update messages to them. For this aim, a new type of Routing extension header is defined: Type MIP Routing header. While Type Xcast Routing header carries the care-of addresses of the mobile nodes, Type MIP Routing header carries the home addresses of the mobile nodes whose entries exist in Binding Cache of the correspondent nodes. The specific protocol operations in Mobile IPv4 and Mobile IPv6 are described in following sections. 3. Protocol operations in Mobile IPv4 A mobile node in Mobile IPv4 registers either a foreign agent care- of address or a co-located care-of address with its home agent while away from home. A mobile node who has registered a foreign agent care-of address is not directly reachable from the outside of the foreign network and is only reachable via the home agent- foreign agent forward tunnel, while a mobile node who has registered a co-located care-of address is directly reachable from the outside of the foreign network with its care-of address. Jiwoong Lee Expire May 2002 [Page 5] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 If a mobile node joins an Xcast session using its home address, Xcast packets of the session will reach its home agent while the mobile node is away from home. Each carries the home address of the mobile nodes within List of Address field. The mobile node, its home agent, and, if registered, its foreign agent require new protocol operations to appropriately handle Xcast packets headed for the mobile node. 3.1. Home agent operations 3.1.1. Requirement for reception If an Xcast-capable home agent has at least one mobility binding for a mobile node, it MUST receive any Xcast packet addressed to All_Xcast_Routers to see if it carries at least one home address of the registered mobile nodes in Xcast header of the packet. 3.1.2. Home agent specific Xcast Routing When a home agent receives an arriving Xcast packet that is addressed to the registered mobile nodes, it performs the following operations over those addresses. The home agent MUST route the Xcast packet based on the care-of addresses which are bound with the home addresses; it determines the appropriate next hops to forward a unicast packet (and thereby an Xcast packet) to the care-of addresses. Next it partitions the home addresses based on the next hops just found and creates Xcast packets such that - one packet per next hop is created - the packet carries a subset of home addresses, which are composed by partitioning process based on the same next hop. If the home agent supports simultaneous bindings for one home address, it MUST include all the bound care-of addresses in Xcast routing process. As a result, the home agent can create plural Xcast packets that carry the same home address in their List of Addresses fields. If only one address is left for a next hop, the home agent MAY perform X2U for that address. Jiwoong Lee Expire May 2002 [Page 6] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 The home agent SHOULD perform the normal Xcast routing over the addresses which are not registered as home addresses of its mobile nodes. Administratively the home agent MAY be configured to perform X2U on every incoming Xcast packet for its registered mobile nodes. This option is helpful when the final recipients are super-sparsely spread and when the intermediate routers do not support Xcast. 3.1.3. Tunneling The home agent SHOULD encapsulate each replicated Xcast packet within an Xcast packet, where the Xcast packet is addressed to the care-of addresses of the addresses listed in the inner packet's List of Address. The List of Addresses of the tunnel header MAY carry foreign-agent care of addresses as well as co-located care-of addresses. (Xcast-in-Xcast encapsulation) Because plural mobile nodes can share the same foreign-agent care- of address, the tunnel Xcast packet MAY be addressed to a single address while the inner one is addressed to plural addresses. In this case the home agent MAY perform X2U over the tunnel header before the transmission, if X bit is not set. (Xcast-in-Unicast encapsulation) 3.2. Foreign agent operations Upon receipt of an encapsulated Xcast datagram sent to its advertised care-of address, a foreign agent MUST check whether each address in inner Xcast header is registered in its visitor list. If not, that address SHOULD be overwritten by zero and MUST be ignored in further processing. Otherwise, the foreign agent processes the inner Xcast packet and forwards it to the mobile nodes in normal way. Because the foreign agent MAY be located on the routing path to the destinations, it MUST perform normal Xcast routing for the addresses shown in List of Addresses of the tunnel header, which are is not its advertised care-of addresses. 3.3. Mobile node operations 3.3.1. Receiving Xcast packets Jiwoong Lee Expire May 2002 [Page 7] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 While a mobile node is away from home, it will receive Xcast packets. If it is registered using a foreign-agent care-of address, they will be forwarded by its foreign agent. Otherwise it will receive encapsulated Xcast packets whose List of Addresses carries the home address of the mobile node and the tunnel header carries the co-located care-of address. Any address which is neither the care-of address nor the home address of the mobile node SHOULD be silently overwritten by zero and MUST be ignored in further processing at the mobile node. 3.3.2. Sending Xcast packets While away from home, a mobile node SHOULD use the default unicast gateway router which is determined by the Mobile IP module of the mobile node when transmitting Xcast packets. If the Xcast module of the mobile node specifies different gateway router as the first hop router for Xcast transmission, it overrides the default gateway router. If the reverse tunneling is negotiated during Mobile IP registration, the mobile node tunnels Xcast packets to its home agent using Xcast-in-Unicast encapsulation where the tunnel header is addressed to the home agent. 3.3.3. Handling packets with turned on Anonymity bit When an mobile node away from home receives an Xcast packet, the 'A' bit (anonymity bit) state in Xcast header MAY NOT affect the packet processing. When a node tunnels an Xcast packet by Xcast-in- Xcast encapsulation, the subsequent Xcast routers perform Xcast routing only over the tunnel header with the Xcast extension information in inner header untouched. Even though the packet source sets A bit, destination mobile nodes will find out other parties' IP addresses without concealment. 4. Protocol Operations over Mobile IPv6 Xcast over Mobile IPv6 has many distinct features that Xcast over Mobile IPv4 does not have. These are rooted at differences between Mobile IPv6 and Mobile IPv4. Some of them which impact upon Xcast are listed as follows: Jiwoong Lee Expire May 2002 [Page 8] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 - Mobile IPv6 does not utilize a foreign agent or a foreign- agent care-of addresses. That is, the mobile node in Mobile IPv6 uses only co-located care-of address. - A correspondent node SHOULD route a packet using Routing extension header, instead of IP-in-IP encapsulation if it has Binding information on the mobile node in its Binding cache. Based on these differences, Xcast over Mobile IPv6 places some special requirements on the functions of Xcast nodes. This section describes operations of Xcast nodes in Mobile IPv6. 4.1. Home agent operations 4.1.1. Requirement for link-local scope multicast packet The current Mobile IPv6 does not allow tunneling of packets addressed to any link-local scope multicast address at a home agent. Since all Xcast packets are addressed to a link-local multicast address, however, the home agent MUST be able to intercept and tunnel incoming packets addressed to a predefined link-local multicast address, All_Xcast_Routers. This requirement updates Mobile IPv6[3]. 4.1.2. Home agent specific Xcast routing When a home agent receives an arriving Xcast packet that carries one or more home addresses of the registered mobile nodes, it performs the following operations over those addresses. The home agent MUST route the Xcast packet based on the care-of addresses which are bound with the home addresses; it determines the appropriate next hops to forward a unicast packet (and thereby an Xcast packet) to the primary care-of addresses. Next it partitions the home addresses based on the next hops just found and creates Xcast packets such that - one packet per next hop is created - the packet carries a subset of home addresses, which are composed by partitioning process based on the same next hop. If only one address is left for a next hop, the home agent MAY perform X2U for that address. Jiwoong Lee Expire May 2002 [Page 9] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 The home agent SHOULD perform the normal Xcast routing over the addresses which are not registered as home addresses of its mobile nodes. Administratively the home agent MAY be configured to perform X2U on every incoming Xcast packet for its registered mobile nodes. This option is helpful when the final recipients are super-sparsely spread and when the intermediate routers do not support Xcast. 4.1.3. Tunneling The home agent SHOULD encapsulate each replicated Xcast packet within an Xcast packet, where the Xcast packet is addressed to the care-of addresses of the addresses listed in the inner packet's List of Address. The List of Addresses of the tunnel header carries co-located care-of addresses. (Xcast-in-Xcast encapsulation) If plural mobile nodes share the same care-of address, or if only one destination address for a next hop is left, the tunnel Xcast packet MAY be addressed to a single address while the inner one can be addressed to plural addresses. In this case the home agent MAY perform X2U over the tunnel header before the transmission, if X bit is not set. (Xcast-in-Unicast encapsulation) The Destination Header, if given in the original packet, is copied to the tunnel header with the following exception: - The Next Header field of Destination Header in the tunnel header MUST be set to indicate the tunneled packet. 4.2. Mobile node operations 4.2.1. Receiving Xcast packets while away from home While away from home, a mobile node will receive Xcast packets. This will be one of the following: - Packets tunneled from the home agent to the primary care-of address of the mobile node. These packets are tunneled using Xcast-in-Unicast encapsulation[9], probably since the Xcast packets processed by the home agent are addressed to a single destination while their X bits are set. On reception the mobile node decapsulates them and re-submits them to its network module, looping back them inside. Jiwoong Lee Expire May 2002 [Page 10] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 - Packets tunneled using Xcast-in-Xcast encapsulation. After the reception, a mobile node decapsulates them and re-submits them to its network module, looping back the packet inside the mobile node. In further processing, packets will be handled as normal Xcast packets, which are containing the home address of the mobile node in List of Addresses. - Packets which are carrying both Type Xcast Routing header and Type MIP Routing header. Type Xcast Routing header contains a care-of address of the mobile node and Type MIP Routing header contains its home address. Any Xcast-capable mobile node who sends Binding Update Request to a correspondent node MUST be able to process Xcast packets that carry both Type Xcast Routing header and Type MIP Routing header at the same time. For the explanation of Type MIP Routing header, see subsection 4.3.1. 4.2.2. Handling packets with turned on Anonymity bit When an mobile node away from home receives an Xcast packet, the 'A' bit (anonymity bit) state MAY NOT affect the packet processing. When a node tunnels an Xcast packet by Xcast-in-Xcast encapsulation, the subsequent Xcast routers perform Xcast routing only over the tunnel header with the Xcast extension information in inner header untouched. Even though the packet source sets A bit, destination mobile nodes will find out other parties' IP addresses without concealment. 4.2.3. Sending Binding Update The mobile node SHOULD return a Binding Update in response to reception of an Xcast packet that meets all of the following tests: - The packet was tunneled using Xcast encapsulation. - The List of Addresses of the tunnel header carries a care-of address of the mobile node. - The List of Addresses of the inner header carries a home address or a previous care-of address of the mobile node. Jiwoong Lee Expire May 2002 [Page 11] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 - The source address in the tunnel header differs from the source address in the inner header. In addition, if the mobile node can deduce that the original sender of the Xcast packet has no or out-of-date Binding Cache entry for the mobile node, it SHOULD return a Binding Update. When a mobile node registers a new care-of address with its home agent, it generally sends Binding Update to every node listed in its Binding Update List. If it is required to immediately send Binding Update messages to a group of nodes, the mobile node MAY send an Xcast packet that carries the addresses of the group nodes in List of Addresses and that also carries both Binding Update option and Home Address option in its Destination header. The Binding Update option MUST carry a care-of address in its Alternate Care-of Address Sub-option. Because Binding Update MUST be protected against malicious security attack, any Xcast packet for that purpose also MUST be protected in some way. Currently no security framework for Xcast over Mobile IP is specified. 4.2.4. Sending Xcast packets while away from home When transmitting, a mobile node MAY send its Xcast packet using either its home address or a care-of address as source of the packet. In case the care-of address is used, the packet SHOULD include the home address in a Home Address Option. 4.3. Correspondent node operations 4.3.1. Definition of Type MIP Routing header Any Mobile IPv6 sending node SHOULD use a Routing header to route a packet to a mobile node whose entry exists in the Binding Cache of the sending node. Mobile IPv6 does not confine the type of this Routing header and it MAY be (mostly) Type 0 one. This document (only within the scope of this document) names the value of type used to build this Routing header "Type MIP" for convenience's sake. ("MIP" stands for Mobile IP.) The value of Type MIP SHOULD be assigned from the Mobile IP module of the sending node, and SHOULD be known to any mobile node communicating with it. If the Mobile IP module does not specify the value of Type MIP to use, the Xcast module on the same implementation MUST use 0 as the value of Type MIP. Jiwoong Lee Expire May 2002 [Page 12] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 4.3.2. Binding update in Xcast packets If a mobile node sends a Binding Update in an Xcast packet to the correspondent nodes, one of them MAY receive the Binding Update in the Xcast packet. Any Xcast node which receives such a packet SHOULD loop-back it after performing X2U to forward to itself. Thereafter the Binding Update will be handled as if it was carried in a unicast packet. 4.3.3. Sending Xcast packets An Xcast sending node SHOULD examine its Binding Cache for an entry for the destination address before sending any Xcast packet to the destination. If the entry is not found, the sending node generates the Xcast packet in normal way in which IP packet is addressed to All_Xcast_Routers and its Type Xcast Routing header includes the addresses of destinations. Otherwise, the sending node SHOULD generate the Xcast packet as follows: - The Type Xcast Routing header lists the care-of addresses of the destinations. - The Type MIP Routing header lists the home addresses of the destinations. - The n-th address listed in the Type Xcast Routing header MUST have the legitimate binding relation with the n-th address listed in the Type MIP Routing header. That is, the binding sequence of addresses in both Routing headers MUST be conserved. - The Type Xcast Routing header MUST precede the Type MIP Routing header. That is, any node who processes Routing header MUST process Type Xcast Routing header before it processes Type MIP Routing header. - The value of Type MIP MUST NOT be zero and SHOULD be known to both the correspondent node and the mobile nodes before transmission. The third rule implies the requirement that the number of the addresses carried in Type Xcast Routing header MUST be the same to that in Type MIP Routing header. An Xcast sending node MUST generate separate copies of Xcast Jiwoong Lee Expire May 2002 [Page 13] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 packets to the mobile nodes whose care-of addresses are found in the Binding Cache and to the nodes whose binding information is not found, in case the sending node wishes to forward the Xcast packet directly to the mobile nodes who are away from home. 4.4. Xcast router considerations 4.4.1. Routing packets with Routing extension header All Xcast routers MUST discard any Xcast packet carrying Type 0 Routing header prior to Type Xcast Routing header performing no more processing over it. All Xcast routers MUST check whether the number of destinations in Type Xcast Routing header is equal to the number of addresses in Type MIP Routing header of any incoming Xcast packet before Xcast routing. If not, whole part of the Type MIP Routing header MUST be copied to every newly generated Xcast packets as a result of Xcast routing. If only one address is left in both Type Xcast Routing header and Type MIP Routing header respectively, the Xcast router MAY perform X2U conversion over the packet. Type MIP routing header MUST remain in the converted packet. If plural addresses are left in Type Xcast and Type MIP Routing headers, the n-th address in Type Xcast Routing header MUST be regarded to have legitimate binding relation with the n-th address in Type MIP Routing header; that is, the former is a care-of address of the latter. The addresses in Type MIP Routing header SHOULD be partitioned according to the result of Xcast routing and each set of partitioned addresses MUST be copied into the Type MIP Routing header of respective each Xcast packet, while the address sequence within the set is reserved. 4.5. Xcast node considerations 4.5.1. General Xcast routing requirement Packets, which enters or are created in a home link where a home agent has Binding Cache entries for registered mobile nodes, MUST be intercepted by the home agent. In order to intercept such packets, the home agent multicast on the home link "gratuitous" Neighbor Advertisement messages [8] on behalf of the mobile nodes. Then Neighbor Caches of Xcast nodes that share the same link with Jiwoong Lee Expire May 2002 [Page 14] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 the home agent have the same target address for the different destination addresses, which are essentially the home addresses of the mobile nodes. Therefore, the Xcast routing over IPv6 MUST be based on the link-local addresses registered in the Neighbor Cache of the forwarding node instead of global scope unicast addresses of the mobile nodes. Otherwise an Xcast node neighboring with the home agent MAY perform X2U over an incoming Xcast packet, which results in that the home agent receives plural unicast packets addressed to each of registered mobile node. 5. Security considerations Parts of the unicast address of the participants in an Xcast session can be revealed to a mobile node when it receives Xcast packets in Xcast-in-Xcast encapsulation. Therefore participant anonymity is broken even though Anonymity bit 'A' of the inner packet is set. A mobile node MAY send its Binding Update to the addresses listed in its Binding Update List simultaneously by sending it in an Xcast packet. How to securely protect this message has been left as an work item for further study. Appendix A. Compatibility statements A.1. Mobile IPv6 HA MUST NOT discard any incoming link-local multicast packets before it performs Xcast processing, if it is Xcast-capable. A.2. All Xcast routers MUST be able to process Xcast packets with Type MIP Routing header. A.3. If an IPv6 node which is not Xcast-capable receives an Xcast packet carrying Type 0 Routing header, it will discard this packet not because the packet is addressed to a multicast address while the packet seems to carry information regarding to loose source routing, but because the packet is addressed to an unregistered link-local address. (Unregistered in its Multicast Forwarding Information Base.) A.4. This document clarifies the requirement of Xcast routing in IPv6 (section 4.5). All Xcast nodes MUST route an Xcast packet based on the link-local addresses of destinations in Neighbor Cache. This is an especially important requirement when a home Jiwoong Lee Expire May 2002 [Page 15] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 agent sends gratuitous Neighbor Advertisement on behalf of its mobile nodes. A.5. Any Xcast packet which is identified with Type Xcast Routing header MUST NOT carry Type 0 Routing header. Section 4.4 of RFC 2460[4] prohibits the appearance of multicast address in Destination field of a packet carrying a Routing header of Type 0. B. Xcast header format Xcast header format for IPv4 and IPv6 are quoted from [XCAST]. B.1. Xcast4 Xcast4 header is inserted between layer 3 header and layer 4 header. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VERSION|A|X|D|P|R| NBR_OF_DEST | CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PROT ID | LENGTH | RESV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHANNEL IDENTIFIER | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of Addresses and DSCPs | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of Port Numbers (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure B.1. B.2. Xcast6 Xcast extension information is carries in Type Xcast Routing extension header in IPv6. Different from Xcast4, the port numbers are carries in a Destination extension header. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen |RouteType=Xcast| 0 | Jiwoong Lee Expire May 2002 [Page 16] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VERSION|A|X|D| R | NBR_OF_DEST | CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHANNEL IDENTIFIER | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of Addresses and DSCPs | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure B.2. Reference [1] R. Boivie, Y. Imai, W. Livens, D. Ooms, and O. Paridaens, Explicit Multicast Basic Specification, draft-ooms-xcast-basic-spec-01.txt, March 2001. [2] C. Perkins, IP Mobility Support for IPv4, revised, draft-ietf- mobileip-rfc2002-bis-06.txt, Jun 2001. [3] D. Johnson and C. Perkins, Mobility Support in IPv6, draft-ietf- mobileip-ipv6-14.txt, July 2001. [4] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Spec- ification, RFC 2460, Dec 1998. [5] S. Deering, Host Extensions for IP Multicasting, RFC 1112, Aug 1989. [6] C. Perkins, IP Encapsulation within IP, RFC 2003, Oct 1996. [7] G. Montenegro, Reverse Tunneling for Mobile IP, revised, RFC 3024, Jan 2001. [8] T. Narten, E. Nordmark, and W. Simpson, Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, Dec 1998. [9] J. Lee, Xcast Encapsulation, draft-lee-xcast-encap-00.txt, (to be released). [10] S. Bradner, Key words for use in RFCs to Indicate Requirement Lev- els, RFC 2119, Mar 1997. Jiwoong Lee Expire May 2002 [Page 17] INTERNET-DRAFT Xcast over Mobile IP Nov 2001 Author Address Jiwoong Lee Korea Telecom Freetel Advanced Lab 1321-11 Seocho-Dong Seocho-Ku Seoul Korea, Republic of Phone : +82-2-3488-0416 Email : porce@ktf.com Myung-Ki Shin ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea Phone : +82-42-860-4847 Fax : +82-42-861-5404 Email : mkshin@pec.etri.re.kr Jiwoong Lee Expire May 2002 [Page 18]