Internet DRAFT - draft-ug-xcast20-protocol-spec
draft-ug-xcast20-protocol-spec
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]
