[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/