INTERNET DRAFT Y. Imai <draft-ug-xcast20-protocol-spec-01.txt> WIDE / Fujitsu T.Kurosawa August 17, 2008 Expires February 17, 2009 XCAST6 (version 2.0) Protocol Specification Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. Copyright Notice Copyright (C) The IETF Trust (2008). All Rights Reserved. Abstract This document describes the specification of Xcast6 (Explicit Multi- unicast (Xcast) for IPv6), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. The difference from the experimental specification which is described in [5058] is that this version eliminates Hop-by-Hop header which sometimes suffers hardware router. Changes Yuji, et al. Expires Februaly 17, 2009 [Page 1]
Internet Draft draft-ug-xcast20-protocol-spec-01.txt August 17, 2008 00->01: add e-mail address of the contributor Table of Contents 1. Introduction 2. Xcast Overview 3. Header 3.1 IPv6 Header for Semi-permeable Tunnel 3.2 IPv6 Header for Original Source & ALL_XCAST_NODES 3.3 Traffic Class and Flow Label 3.4 Hoplimit 3.5 Routing Header 5. IANA consideration 6. Security Consideration 7. Informative Reference 8. Author's Addresses 9. Contributor's Addresses 10. Full Copyright Statement 11. IPR Notices 1. Introduction Discussed in the [5058], XCAST: eXplicit Multi-Unicast is for datagram distribution system suitable for very large number of small group of nodes densely located over the Internet. This documents describes the refined version of XCAST protocol for IPv6. Learn from the experimental operation of protocol version 1.0, we made several modifications to simplify the mechanism and eliminate the deployment obstacles onto the real Internet. We also append detailed descriptions of headers as RFC-editors recommended so as to make the specification well-defined. 2. Xcast Overview XCAST is the complementary multicast mechanism to transmit a packet from one sender node on Internet to two or more receiver just like host group multicast[ASM] and Source Specific Multicast[SSM]. XCAST expresses sets of the reception nodes as explicit list of unicast addresses while two methods mentioned above express it as group address or tuple of source ip address and group address (S,G). Intermediate router can copy and forward XCAST packet by only looking up in the unicast routing table. The detail concept is described in [5058]. 3. Header XCAST6 2.0 datagram is composed of 2 IPv6 headers, 1 routing header, Yuji, et al. Expires Februaly 17, 2009 [Page 2]
Internet Draft draft-ug-xcast20-protocol-spec-01.txt August 17, 2008 transport header and payload, in basic case. [ IPv6(semi-permeable) | IPv6 (inner header) | Routing header | AH/ESP | UDP | Payload ] - IPv6 header for semi-permeable tunnel: The source and destination are changed when the packet is reached to the destination. - IPv6 header for original source and ALL_XCAST_NODE: The original source and ALL_XCAST_NODE are specified respectively. - Routing header The routing header contains the options, a bitmap and a explicit destination list - AH/ESP IPsec header (AH or/and ESP) can appeare in this position. - Transport header UDP header appears in general case. 3.1. IPv6 Header for Semi-permeable Tunnel An XCAST6 2.0 datagram begins with IPv6 header that is for semi- permeable tunnel. Traffic class of XCAST6 header is "010111XX". The 1st 4 bits represent "Experimentally assigned for XCAST6 by IRTF SAM RG" bits, The 5th and 6th bit are for experimental or Local Use as described in [2474] and [4727]. while the remaining 2 bit "XX" is for ECN[3168]. Flowlabel of XCAST6 header is composed of 3 parts. 1st to 8th are "01010111", the ascii code of 'X' (0x58) 9th to 13th are reserved. "00000" by default. 14th to 20th are for the offset of ICMP target that specifies one of the destinations in the address list for which ICMP reflection, echo reply, errors, is not ignored. Detailed semantics are described in Section 3.5. Payload length and hop limit fields are same as in other IPv6 semantics. Next Header should name "IPv6 header"(41) for the 2nd IPv6 header. The source address of an IPv6 header is a unicast address of the source node or address of last branching router, the address of outgoing interface is recommended. The destination address is a unicast address whose IP address appears first in the destination bitmap as specified in Section 3.5. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Yuji, et al. Expires Februaly 17, 2009 [Page 3]
Internet Draft draft-ug-xcast20-protocol-spec-01.txt August 17, 2008 |Version|0 1 0 1 1 1|ECN|0 1 0 1 0 1 1 1| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | NextHdr(41) | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | (transmitter address) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | (head of address list) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2 IPv6 Header for Original Source & ALL_XCAST_NODES The 2nd header is IPv6 header that records original source address and ALL_XCAST_NODE as the destination. This header is basically processed by the nodes or router that is specified by the destination address of the 1st header. If the node is XCAST6-aware, it knows how to process the datagram as an XCAST6 one. In the case node is not XCAST6-aware, the node just drops the datagram because ALL_XCAST_NODE is in the range of group multicast address and RFC2463 requires that nodes must ignore such datagram without any ICMP notification. 3.3 Traffic Class and Flow Label Application can specify the flow label. Intermediate XCAST-aware routers neither read nor modify the flow label. 3.4 Hop Limit The sender node specifies the hop limit of semi-permeable header and the intermediate router decrease it when they forward the packet. Therefore, the maximum length of the stretch of xcast delivery tree is less than 256. If there are xcast-unawere routers, they also decrease it then the maxmum length of daisy chain delivery path is also less than the hoplimit. The hoplimit of inner IPv6 header is always 1, because it is never used. Yuji, et al. Expires Februaly 17, 2009 [Page 4]
Internet Draft draft-ug-xcast20-protocol-spec-01.txt August 17, 2008 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| Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | NextHdr(0xXX)rtg| Hop Limit(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | (original transmitter address) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address = ALL_XCAST_NODE + | (FF0E::114) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.5 Routing Header Complete list of unicast addresses of the destinations is enclosed as a routing optional header. An XCAST6 routing header is defined as a variation of an IPv6 routing header specified by [2460]. Following accordingly RFC2460 the Next Header and Header Extension Length fields are filled with the type of next header and length of the routing header. The type value in the routing header is 253 from experimental range defined in [4727]. [2460] stipulates that when the 4th octet of the routing header is not 0 and its type is not recognized by the router, the router must discard the datagram and reply with an ICMP error to the source of the datagram. This enables DDoS spoofing attacks, if combined with multi-destination delivery. So XCAST6 strongly recommends that 0 always fills the 4th octet of the routing header. That guarantees that routers not aware of the XCAST6 option only discard datagrams without replying with an ICMP error. The number of unicast addresses must be stored in the 5th octet of the routing header. The maximum number of destinations is 126. This restriction relates to the length limit ( 8 * 255 octet) of the routing header itself. The 6th is for A and X bits. 5th is for ICMP error selection. (TBD) In the 9th to 24th octet, the destination bitmap is stored, that Yuji, et al. Expires Februaly 17, 2009 [Page 5]
Internet Draft draft-ug-xcast20-protocol-spec-01.txt August 17, 2008 indicates which unicast destinations in the address list that follows are to be sent to. 1 represents "send-to" and 0 is done. If the number of destinations is less than 126, 0 must fill the following bitmap field. A = Anonymity bit: if this bit is set the destination addresses for which the corresponding bit in the bitmap is zero must be overwritten by zero. X = Xcast bit: if this bit is set a router must not reduce the Xcast packet to unicast packet(s), i.e. the packet must stay an Xcast packet end-to-end. This bit can be useful when IPsec is applied. If this bit is cleared a router should apply X2U if there is only one destination left in the Xcast packet. In some cases a router could decide not to apply X2U to a packet with the Xcast bit cleared, e.g. the router has no directly connected hosts and wants to avoid the extra processing required by X2U. The I bit just before ICMP offset indicates that ICMP offset is valid. If the I bit is set to '1' the receiver of ICMP packet refers to the ICMP offset to decide whether it should reply or not. If it is '0', the receiver silently discard the ICMP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen= |Type=XCAST(253)| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # of dest |A|X|Reserve |I| ICMP offset | RESERVED(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination bitmap + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address #0 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address #1 + | | + + | | Yuji, et al. Expires Februaly 17, 2009 [Page 6]
Internet Draft draft-ug-xcast20-protocol-spec-01.txt August 17, 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ; | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address #n + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. Impact on Upper Layer Protocol XCAST6 datagrams have option headers that are related to other options and upper layer protocols. In this section, we describe the impact on upper layer protocols. The impact is related to the destinations bitmap in the routing header. XCAST6 option is rewritten as it travels along the delivery path. This has an impact on i) checksum calculation in UDP and ICMP headers and ii) IPsec Authentication Header. i) checksum calculation in UDP and ICMP headers In both UDP and ICMP, the target of the checksum calculation includes the pseudo header, transport header and payload. Optional headers are not targeted. In the target, only the destination address of the pseudo header may be rewritten. UDP and ICMP datagrams on XCAST6 must use ALL_XCAST_NODES(FF0E::114) as the destination address of the pseudo header for calculating a checksum. ii) IPsec Authentication header Unlike checksum calculation, optional headers are the target of the calculation of hashed value of the IPsec Authentication header. It must be controlled as to which option should be the target of hash value calculation. (T.B.D.) 5. IANA Consideration Current XCAST6 2.0 uses the following IANA resources from experimental range. IANA should assign the following resources to avoid the confusion when the multiple experiments like XCAST6 2.0 appears. (1) DSCP (2) Multicast Address for ALL_XCAST_NODES Yuji, et al. Expires Februaly 17, 2009 [Page 7]
Internet Draft draft-ug-xcast20-protocol-spec-01.txt August 17, 2008 (3) Routing Type of IPv6 Routing Header (4) Option Type of IPv6 Destination Option Header 6. Security Consideration The counter measure for RH0 problem ( unlimited repeat delivery ) is defining the specification of hoplimit in this document. That is, the router decreases the hoplimit whether it is xcast-aware router or not. And the un-delivered mark '1' of the bitmap field always decreases when it copies the packet. It means the maximum number of the edge of delivery tree of single XCAST packet is 255(hoplimit) * 126(number of bitmap). The maximum stretch of the delivery tree is less than 256. ICMP reflection is prevented by the specification of "the offset of ICMP target" described in section 3.1. It indicates the target to be destinated in the ICMP reply packet. And the attacker cannot use XCAST as ICMP packet amplifier for a specific victim node. The xcast- unaware router sometimes returns the ICMP time exceed. But the destination of the ICMP packet is latest router which copy and forward the XCAST packet.(The maximum number is 126). It might be a method of DOS attack to the xcast-aware router. The counter measure of this attack is TBD. 7. Informative References [5058] R. Boivie, et al., "Explicit Multicast (Xcast) Concepts and Options", RFC 5058, November 2007 [4727] B. Fenner, "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. [ASM] S. Deering, "Multicast Routing in a datagram internetwork", PhD thesis, December 1991. [SSM] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006 [2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998 Yuji, et al. Expires Februaly 17, 2009 [Page 8]
Internet Draft draft-ug-xcast20-protocol-spec-01.txt August 17, 2008 [3168] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001 [2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998 8. Authors Addresses Yuji Imai Fujitsu LABORATORIES Ltd. 1-1, Kamikodanaka 4-Chome, Nakahara-ku, Kawasaki 211-8588, Japan Phone : +81-44-754-2628 Fax : +81-44-754-2793 Email : ug@xcast.jp Takahiro Kurosawa Email : takahiro.kurosawa@gmail.com 9. Contributor Addresses Nobuo Kawaguchi Nagoya University in Japan Email : kawaguti@nagoya-u.jp Elisha Abade Nagoya University in Japan Email : abade@el.itc.nagoya-u.ac.jp Eiichi Muramoto (editor) Matsushita Electric Industrial Co., Ltd. 4-12-4 Higashi-shinagawa, Shinagawa-ku, Tokyo 140-8587, Japan Phone : +81-3-6710-2031 Email : muramoto@xcast.jp 10. Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM Yuji, et al. Expires Februaly 17, 2009 [Page 9]
Internet Draft draft-ug-xcast20-protocol-spec-01.txt August 17, 2008 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11. IPR Notices The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Yuji, et al. Expires Februaly 17, 2009 [Page 10]