INTERNET-DRAFT Jiwoong Lee Expires: July 2003 KTF Advanced Lab 17 January 2003 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 As a special kind of Internet multicast, Explicit multicast(Xcast)[1] encodes destination addresses of all the receivers into the packet. Not requiring membership management and routing information exchange in the intermediate routers in contrast to the legacy Internet multicast or Deering multicast, Xcast 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, route and forward Xcast packets. This document specifies the protocol Jiwoong Lee Expire July 2003 [Page 1] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 operations for the mobile agent, the mobile node and the correspondent node to support transmission and reception of Xcast datagram over Mobile IPv4 and Mobile IPv6. Table of Contents Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview of Xcast over Mobile IP . . . . . . . . . . . . . . . . 4 3. Protocol operations in 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 . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Receiving Xcast packets . . . . . . . . . . . . . . . . . . . 8 3.3.2. Sending Xcast packets . . . . . . . . . . . . . . . . . . . . 8 3.3.3. Handling packets with 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 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. Binding update in Xcast packets . . . . . . . . . . . . . . . 12 4.3.2. Sending Xcast packets . . . . . . . . . . . . . . . . . . . . 12 4.4. Xcast node considerations . . . . . . . . . . . . . . . . . . . 13 4.4.1. General Xcast routing requirement . . . . . . . . . . . . . . 13 5. Security considerations . . . . . . . . . . . . . . . . . . . . . 13 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Jiwoong Lee Expire July 2003 [Page 2] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 A. Compatibility statements . . . . . . . . . . . . . . . . . . . . 14 B. Xcast header format . . . . . . . . . . . . . . . . . . . . . . . 14 C. Changes from Previous Version of the Draft . . . . . . . . . . . 15 D. Future works . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author Address . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 July 2003 [Page 3] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 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 2 Routing extension header A Routing extension header used when a correspondent node directly forwards a packet to a mobile node in Mobile IPv6 as a way of routing optimization. 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 2 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 Jiwoong Lee Expire July 2003 [Page 4] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 predefined link-local multicast address, the home agent MUST be 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 a special manner to home agents. The home agent first looks up the care-of addresses that are 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 tunnels 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 addition, Xcast over Mobile IPv6 prohibits a correspondent node from using Type 2 Routing Extension Header as a mean of routing optimization. For the goal of routing optimization, the correspondent node MUST use Xcast-in-Xcast encapsulation, or Xcast- in-Unicast encapsulation. 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. If a mobile node joins an Xcast session using its home address, Jiwoong Lee Expire July 2003 [Page 5] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 Xcast packets belonging to the session will reach its home agent while the mobile node is away from home. Each packet carries the home addresses of the mobile nodes in List of Address field. The mobile node, its home agent, and, if registered, its foreign agent require following protocol operations to appropriately handle Xcast packets heading 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 (defined in [1]) to see if it is addressed to at least one home address of the registered mobile nodes. 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 any unicast packet (and thereby the Xcast packet) to the care-of addresses. Next it partitions the home addresses based on the just-found next hops just found and creates Xcast packets such that - one packet per next hop is created - the packet is addressed to a subset of the listed home addresses, which is 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 X-in-U tunneling[TUNNEL] for that address. Jiwoong Lee Expire July 2003 [Page 6] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 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 X-in-U tunneling on every incoming Xcast packet for its registered mobile nodes. This option is helpful when the final recipients are super- sparsely spread over the Internet 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 tunnel Xcast packet is addressed to the care-of addresses of the addresses listed in the original 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). How to build up a tunnel packet is out of the scope of this document. Explicit multicast tunneling is defined in [9]. Since plural mobile nodes can share the same foreign-agent care-of address, the tunnel Xcast packet MAY be addressed to the same addresses while the inner one is addressed to different addresses. In this case the home agent MAY send the original packet in Xcast- in-Unicast tunneling, if X bit of the original packet is set. 3.2. Foreign agent operations Upon receipt of an tunneled Xcast packet sent to its advertised care-of addresses, a foreign agent MUST check whether each address in List of Addresses of the original 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. When decapsulated, the bitmap of the original packet MUST inherit from that of the tunnel packet, as described in [9]. 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 not its advertised care-of addresses. Jiwoong Lee Expire July 2003 [Page 7] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 3.3. Mobile node operations 3.3.1. Receiving Xcast packets While a mobile node is away from home, it can 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 tunneled Xcast packets. If no address in List of Addresses matches the home address of the mobile node, this tunneled Xcast packet MUST be discarded. Duplicate home address in List of Addresses SHOULD be ignored. 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 Anonymity bit When a 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 while the original header remains untouched. Even though the packet sender sets A bit, tunnel egress nodes can find out receivers' IP addresses without concealment. 4. Protocol Operations over Mobile IPv6 Jiwoong Lee Expire July 2003 [Page 8] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 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: - 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[3] does not allow tunneling of multicast packets with link-local scope received by a home agent. Since an Xcast packet is addressed to All_Xcast_Routers, which is a link- local scope multicast address, a home agent SHOULD intercept packets addressed to All_Xcast_Routers, or Xcast packet MUST be addressed to a multicast address with larger scope than link-local. 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 any unicast packet (and thereby the Xcast packet) to the primary care-of addresses. Next it partitions the home addresses based on the just-found next hops just found and creates Xcast packets such that - one packet per next hop is created Jiwoong Lee Expire July 2003 [Page 9] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 - the packet is addressed to a subset of the listed home addresses, which is 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 X-in-U tunneling for that address. 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 X-in-U tunneling on every incoming Xcast packet for its registered mobile nodes. This option is helpful when the final recipients are super- sparsely spread over the Internet 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 tunneling Xcast packet is addressed to the care-of addresses of the addresses listed in the original packet's List of Address. The List of Addresses of the tunnel header carries co-located care-of addresses. (Xcast-in-Xcast encapsulation) When one address is left in List of Addresses for a next hop as a result of Xcast routing, the home agent MAY encapsulated the original packet within unicast tunnel packet. The tunnel packet is addressed to the care-of address of the mobile node, 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: Jiwoong Lee Expire July 2003 [Page 10] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 - 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]. On reception the mobile node decapsulates them and re-submits them to its network module, looping back them inside. - 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. During the decapsulation, the bit inheritance MUST be done. 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. 4.2.2. Handling packets with Anonymity bit When an mobile node away from home receives an Xcast packet, the Anonymity bit state MAY NOT affect the packet processing. When a home agent tunnels an Xcast packet by Xcast-in-Xcast encapsulation, the intermediate Xcast routers perform Xcast routing only over the tunnel header leaving the original header untouched. Even though the packet sender sets A bit, destination mobile nodes will find out other parties' IP addresses without concealment. 4.2.3. Sending Binding Update A 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 original header carries a home address or a previous care-of address of the mobile node. - The source address in the tunnel header differs from the source address in the original 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. Jiwoong Lee Expire July 2003 [Page 11] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 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. 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 that receives such a packet SHOULD loop-back it after performing X2U to forward the packet to itself. Thereafter the Binding Update will be handled as if it was carried in a unicast packet. 4.3.2. 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 send the Xcast packet after Xcast encapsulation. The sending node MUST NOT use Type 2 Routing Extension Header as a mean of routing optimization. That is, the Jiwoong Lee Expire July 2003 [Page 12] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 sending node SHOULD generate the tunneled Xcast packet such that - The Type Xcast Routing Extension Header of the original packet encodes the home addresses of the mobile nodes - The Type Xcast Routing Extension Header of the tunnel packet encodes the care-of addresses of the mobile nodes - The n-th address listed in the Type Xcast Routing Extension header of the tunnel packet MUST have the legitimate binding relation with the n-th address listed in the Type Xcast Routing Extension header of the original packet. That is, the binding sequence of addresses in both Routing headers MUST be conserved. An Xcast sending node MUST generate separate copies of Xcast packets either to the mobile nodes whose care-of addresses are found in the Binding Cache and or 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 node considerations 4.4.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 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 Jiwoong Lee Expire July 2003 [Page 13] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 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 original 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. This document clarifies the requirement of Xcast routing in IPv6 (section 4.4). 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 agent sends gratuitous Neighbor Advertisement on behalf of its mobile nodes. 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 | Jiwoong Lee Expire July 2003 [Page 14] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VERSION|A|X|D| R | NBR_OF_DEST | CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHANNEL IDENTIFIER | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of Addresses and DSCPs | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure B.2. C. Changes from Previous Version of the Draft This appendix briefly lists some of the major changes in this draft relative to the previous version of this same draft, draft-lee- xcast-mobileip-00.txt: - Clarified the usage of X-in-U tunneling instead of performing X2U over the tunnel packet. - Removed the use of Type Xcast Routing Extension header and Type MIP Routing Extension header as a mean of routing opti- mization of the sending node. Jiwoong Lee Expire July 2003 [Page 15] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 - Refereed to [9] on the matters of how to build up a tunnel packet and how to decapsulate a tunnel packet. - Clarified the requirement of home agent when it intercepts a multicast packet with link-local scope. - Changed expressions in order to clarify the protocol opera- tions. - Corrected some editorial nits. D. Future works - In Mobile IPv6, Binding Update in Xcast packet should be explained in greater detail. - Appendix A.2 of this document can be revised neatly. Reference [1] R. Boivie, Y. Imai, W. Livens, D. Ooms, and O. Paridaens, Explicit Multicast Basic Specification, draft-ooms-xcast-basic-spec-03.txt, June 2002. [2] C. Perkins, IP Mobility Support for IPv4, RFC 3344, IETF, Aug 2002. [3] D. Johnson and C. Perkins, Mobility Support in IPv6, draft-ietf- mobileip-ipv6-16.txt, Oct 2002. [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, Explicit multicast tunneling, draft-lee-xcast-tunnel- ing-01.txt, Aug 2002. Jiwoong Lee Expire July 2003 [Page 16] INTERNET-DRAFT Xcast over Mobile IP Jan 2003 [10] S. Bradner, Key words for use in RFCs to Indicate Requirement Lev- els, RFC 2119, Mar 1997. Author Address Jiwoong Lee KT Freetel Advanced Lab 1321-11 Seocho-Dong Seocho-Ku Seoul Korea, Republic of Phone : +82-2-3488-0416 Email : porce@ktf.com Jiwoong Lee Expire July 2003 [Page 17]