CLUE protocol
draft-ietf-clue-protocol-09
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8847.
|
|
|---|---|---|---|
| Authors | Roberta Presta , Simon Pietro Romano | ||
| Last updated | 2016-08-13 | ||
| Replaces | draft-presta-clue-protocol | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Paul Kyzivat | ||
| IESG | IESG state | Became RFC 8847 (Experimental) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | "Daniel C. Burnett" <danielcburnett@gmail.com>, "Paul Kyzivat" <pkyzivat@alum.mit.edu> |
draft-ietf-clue-protocol-09
IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH
Updates: 6564 (if approved) W. Liu
Intended status: Standards Track Huawei Technologies
Expires: August 4, 2014 January 31, 2014
IPv6 Universal Extension Header
draft-gont-6man-ipv6-universal-extension-header-00
Abstract
This document analyzes a problem in the Uniform Format for IPv6
Extension Headers specified in RFC 6564, which results in forwarding
nodes and middle-boxes not being able to process an IPv6 Header Chain
if it contains an unrecognized IPv6 Extension Header that follows the
aforementioned Uniform Format. Additionally, it specifies a new IPv6
Extension Header - the Universal Extension Header - that overcomes
the aforementioned problem, and enables the extensibility of IPv6
without impairing middleboxes that need to process the entire IPv6
Header Chain. Finally, this document formally updates RFC 6564
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 4, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Gont & Liu Expires August 4, 2014 [Page 1]
Internet-Draft Universal Extension Header January 2014
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Updating RFC 6564 . . . . . . . . . . . . . . . . . . . . . . 3
5. Operation of the Universal Extension Header . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
10.1. Normative References . . . . . . . . . . . . . . . . . . 5
10.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
There has recently been a lot of work about IPv6 Extension Headers.
Firstly, there has been research about the extent to which IPv6
Extension Headers are dropped in the public Internet [GONT-IEPG], and
debate about the motivation behind such policy
[I-D.taylor-v6ops-fragdrop]. Secondly, there has been a fair share
of work to improve some technicalities of IPv6 Extension Headers
[I-D.ietf-6man-oversized-header-chain] [RFC7045], in the hopes that
they can be reliably used in the public Internet.
A key challenge for IPv6 Extension Headers to be "usable" in the
public Internet is that they should not impair any middle-box's
ability to inspect the upper layer header (e.g., TCP source and
destination ports, etc.). One of the steps in that direction has
been the specification of a Uniform Format for IPv6 Extension Headers
[RFC6564], which is meant to be employed by any IPv6 Extension
Headers that might be defined in the future, such that middle-boxes
can still process the entire IPv6 header chain if the new extension
headers employ the Uniform Format.
Section 3 discusses a flaw in the Uniform Format for Extension
Headers specified in [RFC6564]. Section 4 formally updates
[RFC6564], specifying the new Universal Extension Header (UEH).
Section 5 explains how new IPv6 would be developed with the UEH.
Gont & Liu Expires August 4, 2014 [Page 2]
Internet-Draft Universal Extension Header January 2014
2. Terminology
The key words "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 [RFC2119].
3. Problem Statement
A key problem with the Uniform Format for IPv6 Extension Headers lies
on the fat that both IPv6 Extension Headers and Transport Protocols
share the same namespace ("Next Header" registry/namespace). Thus,
there is now way to distinguish between an unrecognized IPv6
Extension Header and an unrecognized transport protocol. For
example, if a node were to receive an IPv6 packet that employs an
unsupported "Next Header" value, there is no way to tell whether the
next header corresponds to an Extension Header employing the Uniform
Format for IPv6 Extension Headers, or a new upper-layer protocol
(such as a transport protocol).
Clearly, employing the Uniform Format for IPv6 Extension Headers
"enables" the future extension of IPv6 and the processing of entire
IPv6 header chains containing unrecognized extension headers, at the
expense of preventing the deployment of new transport protocols or
other upper layer protocols.
4. Updating RFC 6564
The entire Section 4 of [RFC6564] is hereby replaced as follows:
New IPv6 Extension Headers MUST NOT be specified. Any IPv6
extensions that would require a new IPv6 Extension Header MUST be
implemented with the Universal Extension Header specified in this
document. This minimizes breakage in intermediate nodes that examine
these extension headers.
This document specifies a new IPv6 Extension Header: Universal
Extension Header. This Extension Header is identified by the value
[TBD] of [IANA-IP-PROTO]. The syntax of the Universal Extension
Header is:
Gont & Liu Expires August 4, 2014 [Page 3]
Internet-Draft Universal Extension Header January 2014
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 | Hdr Ext Len | Subtype | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Subtype Specific Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Next Header
8-bit selector. Identifies the type of header immediately
following the extension header. Uses the same values as the IPv4
Protocol field [IANA-IP-PROTO].
Hdr Ext Len
8-bit unsigned integer. Length of the extension header in 8-octet
units, not including the first 8 octets.
Subtype
8-bit unsigned integer. Specifies the subtype for this extension
header. It uses a new namespace managed by IANA [IANA-UEH].
Subtype Specific Data
Variable length. Fields specific to this extension header/
Subtype.
The Universal Extension Header specified in this document MAY appear
multiple times in the same IPv6 packet.
5. Operation of the Universal Extension Header
This section discusses de operation of the Universal Extension
Header.
The goal of the UEH is to provide for a common syntax for all future
IPv6 extensions. Any future extension headers will be encoded in a
UEH, and will be identified by a specific UEH Subtype assigned by
IANA at the time the corresponding specification is published. The
UEH thus provides for the "common syntax" required to process
"unrecognized extensions", and the Subtype field identifies the
specific extension being encoded in the UEH. Any "future extension
Gont & Liu Expires August 4, 2014 [Page 4]
Internet-Draft Universal Extension Header January 2014
& email address to contact for further information: Simon
Pietro Romano (spromano@unina.it).
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: This media type is a specialization of
application/xml [RFC7303], and many of the considerations described
there also apply to application/clue+xml.
12.4. CLUE Protocol Registry
The document requests that the IANA creates new registries for CLUE
messages and response codes.
12.4.1. CLUE Message Types
The following summarizes the registry for CLUE messages:
Related Registry: CLUE Message Types Registry
Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]]
Presta & Romano Expires February 14, 2017 [Page 48]
Internet-Draft draft-ietf-clue-protocol-09 August 2016
Registration/Assignment Procedures: Following the policies outlined
in [RFC5226], the IANA policy for assigning new values for the CLUE
message types for the CLUE protocol is Specification Required.
Registrant Contact: IETF CLUE working group (clue@ietf.org), Simon
Pietro Romano (spromano@unina.it).
The initial Message table is populated using the CLUE messages
described in Section 5 and defined in the XML schema in Section 9.
+-------------------+-----------------------------------+-----------+
| Message | Description | Reference |
+-------------------+-----------------------------------+-----------+
| options | "OPTIONS" in this document. Sent | RFCXXXX |
| | by the CI to the CR in the | |
| | initiation phase to specify the | |
| | roles played by the CI, the | |
| | supported versions and the | |
| | supported protocol options. | |
| optionsResponse | "OPTIONS RESPONSE" in this | RFCXXXX |
| | document. Sent by the CI to the | |
| | CR in reply to an OPTIONS message | |
| | to finally estabilsh the version | |
| | and the options to be used in the | |
| | following CLUE messages exchange. | |
| advertisement | "ADVERTISEMENT" or "ADV" in this | RFCXXXX |
| | document. Sent by the MP to the | |
| | MC to specify the telepresence | |
| | capabilities of the MP expressed | |
| | according to the CLUE framework. | |
| ack | "ACK" in this document. Sent by | RFCXXXX |
| | the MC to the MP to acknowledge | |
| | the reception of an ADVERTISEMENT | |
| | message. | |
| configure | "CONFIGURE" or "CONF" in this | RFCXXXX |
| | document. Sent by the MC to the | |
| | MP to specify the desired media | |
| | captures among those specified in | |
| | the ADVERTISEMENT. | |
| configureResponse | "CONFIGURE RESPONSE" or "CONF | RFCXXXX |
| | RESPONSE" in this document. Sent | |
| | by the MP to the MC in reply to a | |
| | CONFIGURE message to communicate | |
| | if the configuration request has | |
| | been successfully processed or | |
| | not. | |
+-------------------+-----------------------------------+-----------+
Presta & Romano Expires February 14, 2017 [Page 49]
Internet-Draft draft-ietf-clue-protocol-09 August 2016
IANA-CLUE
12.4.2. CLUE Response Codes
The following summarizes the requested registry for CLUE response
codes:
Related Registry: CLUE Response Code Registry
Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]]
Registration/Assignment Procedures: Following the policies outlined
in [RFC5226], the IANA policy for assigning new values for the
Response codes for CLUE shall be Specification Required.
Registrant Contact: IETF CLUE working group (clue@ietf.org), Simon
Pietro Romano (spromano@unina.it).
The initial Response-code table is populated using the Response codes
defined in Section 5.7 as follows:
+--------+-----------------+----------------------------+-----------+
| Number | Default | Description | Reference |
| | Response String | | |
+--------+-----------------+----------------------------+-----------+
| 200 | Success | The request has been | RFCXXXX |
| | | successfully processed. | |
| 300 | Syntax errors | The XML syntax of the | RFCXXXX |
| | and | message is not correct or | |
| | inconsistencies | there are invalid values. | |
| 301 | Bad syntax | The XML syntax of the | RFCXXXX |
| | | message is not correct. | |
| 302 | Invalid value | The message contains an | RFCXXXX |
| | | invalid parameter value. | |
| 303 | Conficting | The message contains | RFCXXXX |
| | values | values that cannot be used | |
| | | together. | |
| 400 | Semantic errors | Semantic errors in the | RFCXXXX |
| | | received CLUE protocol | |
| | | message. | |
| 401 | Version not | The protocol version used | RFCXXXX |
| | supported | in the message is not | |
| | | supported. | |
| 402 | Invalid | The sequence number of the | RFCXXXX |
| | sequencing | message is out of date. | |
Presta & Romano Expires February 14, 2017 [Page 50]
Internet-Draft draft-ietf-clue-protocol-09 August 2016
| 403 | Invalid | The identifier used in the | RFCXXXX |
| | identifier | message is no valid or | |
| | | unknown. | |
| 404 | ADV Expired | The number of the ADV the | RFCXXXX |
| | | CONF refers to is out of | |
| | | date. | |
| 405 | Subset choice | The subset choice is not | RFCXXXX |
| | not allowed | allowed for the specified | |
| | | MCC. | |
+--------+-----------------+----------------------------+-----------+
13. Diff with draft-ietf-clue-protocol-06
o XML schema definition of <version> has been changed to match
pattern "X.Y", where X and Y are single digits.
o 100, 200, 300, 400 defined as catch-all response codes.
o Updates in IANA section.
14. Diff with draft-ietf-clue-protocol-05
o This document corrects some versioning errors of
draft-ietf-clue-protocol-05.
15. Diff with draft-ietf-clue-protocol-04
o The document has been revised based on feedback recevied on the
ML. No major modification is included in this version.
16. Diff with draft-ietf-clue-protocol-03
o Response codes section updated.
o maxCaptureEncodings removed from examples, allowSubsetChoice
added.
o State machines descriptions aligned with pictures.
o Applied recommended updates indicated in Christian's review (2015-
03-19).
17. Diff with draft-ietf-clue-protocol-02
o CLUE Participant state machine: TERMINATED state replaced with
IDLE.
Presta & Romano Expires February 14, 2017 [Page 51]
Internet-Draft draft-ietf-clue-protocol-09 August 2016
o MP and MC state machines: SDP O/A state removed.
o Diff mechanism (and related example) removed.
o Schema updates: versionType used as the data type for all versions
fields, xs:unsignedInt used as the data type for all sequence
number fields, diff support removed from the ADV definition.
18. Diff with draft-ietf-clue-protocol-01
o The diff mechanism for the ADV message has been introduced.
o READV and READV RESPONSE message have been both removed.
o The state machines have been deeply reviewed and changed.
o References: references have been updated and splitted into
Informative references and Normative references as in framework
v17.
o Schema: <globalSceneEntries> changed in <globalViews>,
<participants> in <people>
o Terminology: many definitions added.
o Response codes updated.
19. Diff with draft-ietf-clue-protocol-00
1. The XML schema of the ADVERTISEMENT and of the READV have been
aligned with the current definitions in
[I-D.ietf-clue-data-model-schema] (example of updates:
<participants> --> <people>, <globalCaptureEntries> -->
<globalSceneEntries>)
2. Text has been added to clarify that, in the OPTIONS RESPONSE,
when the response code is not an error response code, both
<mediaProvider> and <mediaConsumer> are mandatory.
3. The content of the "v" attribute and of the <version> elements
carried in the OPTIONS and OPTIONS RESPONSE messages has been
described more precisely.
4. Advertisement examples have been added.
Presta & Romano Expires February 14, 2017 [Page 52]
Internet-Draft draft-ietf-clue-protocol-09 August 2016
20. Diff with draft-presta-clue-protocol-04
1. The response code type error in the OPTIONS response (and in
other parts) has been corrected.
21. Diff with draft-presta-clue-protocol-03
1. The XML Schema has been deeply revised and completed.
2. The descriptions of the CLUE messages have been added.
3. The distinction between major version numbers and minor version
numbers has been cut and pasted from [I-D.ietf-clue-signaling].
4. Besides the two way one, a three way mechanism for the options
negotiation has been proposed and provided to foster discussion.
22. Diff with draft-presta-clue-protocol-02
1. "Terminology" section added.
2. Introduced the concept of "CLUE Participant" - an Endpoint or a
MCU able to use the CLUE protocol within a telepresence session.
A CLUE Participant can act as a Media Provider and/or as a Media
Consumer.
3. Introduced the ACK/NACK mechanism for the ADVERTISEMENT.
4. MP and MC state machines have been updated. The CP state machine
has been added.
23. Acknowledgments
The authors thank all the CLUErs for their precious feedbacks and
support, in particular Paul Kyzivat, Christian Groves and Scarlett
Liuyan.
24. References
24.1. Normative References
[I-D.ietf-clue-data-model-schema] Presta, R. and S. Romano, "An XML
Schema for the CLUE data model", d
raft-ietf-clue-data-model-schema-
16 (work in progress), June 2016.
[I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol data
channel",
Presta & Romano Expires February 14, 2017 [Page 53]
Internet-Draft draft-ietf-clue-protocol-09 August 2016
draft-ietf-clue-datachannel-14
(work in progress), August 2016.
[I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and
S. Wenger, "Framework for
Telepresence Multi-Streams",
draft-ietf-clue-framework-25 (work
in progress), January 2016.
[I-D.ietf-clue-signaling] Kyzivat, P., Xiao, L., Groves, C.,
and R. Hansen, "CLUE Signaling",
draft-ietf-clue-signaling-09 (work
in progress), March 2016.
[RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/
rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S.,
Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for
Real-Time Applications", STD 64,
RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://
www.rfc-editor.org/info/rfc3550>.
[RFC3688] Mealling, M., "The IETF XML
Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688,
January 2004, <http://
www.rfc-editor.org/info/rfc3688>.
[RFC3958] Daigle, L. and A. Newton, "Domain-
Based Application Service Location
Using SRV RRs and the Dynamic
Delegation Discovery Service
(DDDS)", RFC 3958, DOI 10.17487/
RFC3958, January 2005, <http://
www.rfc-editor.org/info/rfc3958>.
[RFC5226] Narten, T. and H. Alvestrand,
"Guidelines for Writing an IANA
Considerations Section in RFCs",
BCP 26, RFC 5226, DOI 10.17487/
RFC5226, May 2008, <http://
Presta & Romano Expires February 14, 2017 [Page 54]
Internet-Draft draft-ietf-clue-protocol-09 August 2016
www.rfc-editor.org/info/rfc5226>.
[RFC7303] Thompson, H. and C. Lilley, "XML
Media Types", RFC 7303,
DOI 10.17487/RFC7303, July 2014, <
http://www.rfc-editor.org/info/
rfc7303>.
24.2. Informative References
[RFC1122] Braden, R., Ed., "Requirements for
Internet Hosts - Communication
Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122,
October 1989, <http://
www.rfc-editor.org/info/rfc1122>.
[RFC4353] Rosenberg, J., "A Framework for
Conferencing with the Session
Initiation Protocol (SIP)",
RFC 4353, DOI 10.17487/RFC4353,
February 2006, <http://
www.rfc-editor.org/info/rfc4353>.
[RFC6120] Saint-Andre, P., "Extensible
Messaging and Presence Protocol
(XMPP): Core", RFC 6120,
DOI 10.17487/RFC6120, March 2011,
<http://www.rfc-editor.org/info/
rfc6120>.
[RFC7262] Romanow, A., Botzko, S., and M.
Barnes, "Requirements for
Telepresence Multistreams",
RFC 7262, DOI 10.17487/RFC7262,
June 2014, <http://
www.rfc-editor.org/info/rfc7262>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP
Topologies", RFC 7667,
DOI 10.17487/RFC7667,
November 2015, <http://
www.rfc-editor.org/info/rfc7667>.
Presta & Romano Expires February 14, 2017 [Page 55]
Internet-Draft draft-ietf-clue-protocol-09 August 2016
Authors' Addresses
Roberta Presta
University of Napoli
Via Claudio 21
Napoli 80125
Italy
EMail: roberta.presta@unina.it
Simon Pietro Romano
University of Napoli
Via Claudio 21
Napoli 80125
Italy
EMail: spromano@unina.it
Presta & Romano Expires February 14, 2017 [Page 56]