Guidelines for Usage of Interactive Connectivity Establishment (ICE)by non Session Initiation Protocol (SIP) Protocols
draft-rosenberg-mmusic-ice-nonsip-01

Status of this Memo

By submitting this Internet-Draft,each author represents that any applicable patent or other IPR claims of whichhe 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 EngineeringTask Force (IETF), its areas, and its working groups.Note that other groups may also distribute working documents asInternet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at any time.It is inappropriate to use Internet-Drafts as reference material or to citethem other than as “work in progress.”

The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 15, 2009.

Abstract

Interative Connectivity Establishment (ICE) has been specified as a NAT traversal mechanism for protocols based on the offer/answer exchange model. In practice, only the Session Initiation Protocol (SIP) has used ICE. This document provides guidance on how other protocols can make use of ICE.

Table of Contents

1. Introduction
2. Can My Protocol Use ICE?
3. Target Architecture
4. General Considerations
    4.1. Lite Implementation
    4.2. Multiple Components
    4.3. Multiple Media Streams
5. ICE Functions
    5.1. Gathering of Candidates
        5.1.1. Candidate types
        5.1.2. Pacing
        5.1.3. Number and Discovery of Servers
        5.1.4. Other Protocols
        5.1.5. Prioritization
        5.1.6. Default Candidates
    5.2. Initial Exchange of Candidates
        5.2.1. ICE Mismatch
        5.2.2. Parameter Encoding
        5.2.3. Role Determination
    5.3. Connectivity Checks
        5.3.1. Scheduling Checks
    5.4. Conclusion of ICE
        5.4.1. Regular vs. Aggressive Nomination
        5.4.2. Updated Signaling and Remote Candidates
    5.5. Subsequent Signaling
    5.6. Media and Keepalives
6. Security Considerations
7. IANA Considerations
8. Informative References
§ Author's Address
§ Intellectual Property and Copyright Statements

1. Introduction

Interactive Connectivity Establishment (ICE)[I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) has been specified by theIETF as a mechanism for NAT traversal for protocols based on theoffer/answer model[RFC3264] (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.), which exchanges SessionDescription Protocol (SDP)[RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) objects tonegotiate media sessions.

ICE has many benefits. It is automated, relying on very littleconfiguration. It works through an extremely broad range of networkand NAT topologies. It is robust, establishing connections in manychallenging environments. It is efficient, utilizing relays andintermediaries only when other options will not work. At the time ofwriting, ICE has seen widespread usage on the Internet for traversalof Voice over IP, primarily based on the Session Initiation Protocol(SIP)[RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)

However, SIP is not the only protocol that requires the establishmentof host-to-host relationships for communications. Consequently, ICEhas recently been considered as the NAT traversal technique for otherprotocols. These include Peer-to-Peer SIP (P2PSIP)[I‑D.bryan‑p2psip‑reload] (Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD),” June 2008.), Host Identity Protocol (HIP)[I‑D.manyfolks‑hip‑sturn] (Nikander, P., Melen, J., Komu, M., and M. Bagnulo, “Mapping STUN and TURN messages on HIP,” November 2007.) and Mobile IP v6[I‑D.tschofenig‑mip6‑ice] (Tschofenig, H., “Mobile IP Interactive Connectivity Establishment (M-ICE),” February 2008.). In each case, theprotocol in question provides a mechanism for two hosts to rendezvousthrough some intermediary, and then needs a host-to-host connectionestablished. This fits the NAT traversal capability provided by ICE.

Unfortunately, the ICE specification itself is intertwined with SDPand the offer/answer model, and is not immediately usable by protocolsthat do not utilize offer/answer. For this reason, each of theseprotocols need to define how to utilize ICE for their specificneeds. This document provides guidelines for authors of suchspecifications. It includes guidance on when ICE can be used by aprotocol, describes each of ICE's major functions and how they can beapplied.

This document assumes the reader is familiar with ICE and itsoperation.

2. Can My Protocol Use ICE?

Not all protocols can make use of ICE. ICE works only with protocolsthat fit the pattern of a session protocol. A session protocol is onein which there exists some kind of rendezvous service, typicallythrough a server on the Internet, by which hosts can contact eachother. Through the rendezvous service, hosts can exchange informationfor the purposes of negotiating a direct host to host connection. Eachhost is assumed to have an identifier by which it is known to therendezvous service, and by which other hosts can identify it. There istypically some kind of registration operation, by which a hostconnects to the rendezvous service and identifies itself. Thisprotocol design pattern is shown inFigure 1 (Session Protocols).

                      +--------------+                      |              |                      |              |                   >  |  Rendezvous  | \                  /   |    Service   |  \                 /    |              |   \                /     |              |    \               /      |              |     \              /       +--------------+      \             /                               \            /  Connect                        \           /   To Y                            \          /                                     \     +--------+                            +--------+     |        |                            |        |     |        |                            |        |     |  Host  |  ......................... |  Host  |     | ID:X   |                            | ID:Y   |     |        |                            |        |     +--------+                            +--------+

If hosts can reach each other through the rendezvous service, whycreate direct connections? Typically, the rendezvous service providesan indirect connection, and may be very suboptimal in terms of latencyand other path metrics. The rendezvous service may also have limitedbandwidth, and not be capable of supporting the volume of datarequired to flow between the hosts.

As an example, in SIP, the rendezvous service is the SIP server. Theidentifier is the SIP URI. The registration process is supported usingthe SIP REGISTER method. Connections are established using the INVITEmethod.

For a protocol to use ICE, it must exhibit the properties ofa session protocol as described above. Furthermore, it must provide amechanism for exchanging information between the hosts for purposesof establishing the connection. It must provide for, at least, onemessage from the initiator to the other host, and one message back. Ifall of these criteria are met, ICE can be used.

3. Target Architecture

The goal of the recommendations in this document is to enable anarchitecture for firewall and NAT traversal across many protocols thathas two properties:

1. STUN and TURN servers can be used to support multiple applications
2. Gateways can easily be built between ICE-using protocols that arecompatible

The second of these requires further discussion. In some cases, twodifferent protocols are ones that provide similar functions, so thatit is reasonable to build gateways between them. For example, gatewaysbetween SIP and H.323, or between SIP and RTSP, are reasonable thingsto do. A gateway function between two session protocols needs toconcern itself with converting the signaling and converting the mediaprotocol - whether it be RTP or something else. It is highly desirableto avoid actual conversion operations along the direct mediapath. These greatly increase the cost and complexity of gatewayfunctions. Consequently, the ideal architecture looks like this:

                             +---------+                             |  STUN/  |         STUN/TURN           |  TURN   |         STUN/TURN   **************************| Servers |****************************   *                         |         |                           *   *                         +---------+                           *   *                                                               *   *                                                               *   *                                                               *   *                                                               *   *                                                               *   *   +------------+                            +------------+    *   *   |  Signaling |         +-------+          |  Signaling |    *   *   |   Server   |    A    |       |     B    |   Server   |    *   *   |            |<------->|  GW   |<-------->|            |    *   *   | Protocol A |         |       |          | Protocol B |    *   *   |            |         +-------+          |            |    *   *   +------------+                            +------------+    *   *          |                                         |          *   *          |                                         |          *   *          |                                         |          *   *          |                                         |          *   *          |                                         |          *   *          |                                         |          *   *          |                                         |          *   *          |                media +                  |          *   *                           checks                              *   *      ///----\\\                                ///----\\\     *   **** || Client 1 || .......................... || Client 1 ||****          \\\----///                                \\\----///

In this architecture, clients of two different protocols (A and B)make use of signaling servers for their respective protocols. There isa gateway function between them, but this function ONLY concernsitself with the signaling. The content of the established sessions -which includes the media and the path-based connectivity checks thatICE uses - do not require any protocol conversion.

Of course, implementations can choose to gateway the media and checksif they want, but it is a strong objective of the recommendations herethat they don't HAVE TO.

The architecture also shows that the goal is to have a common set ofTURN and STUN functions that serve all applications using ICE.

4. General Considerations

There are some general considerations for the using protocol.

4.1. Lite Implementation

The lite mode of operation for ICE allows for usage by agents whichare always reachable by any other agent, both now and in thefuture. The using protocol needs to decide whether this mode ofoperation is supported or not. If not, all agents will be fullimplementations. If the mode is supported, agents can either be liteor full.

The principal consideration is the likelihood of agents being alwayspublicly reachable, vs. the cost of an ICE implementation. ICE itselfprovides strong caution against the lite mode of implementation. It isvery easy for protocol designers to envision specific scenarios fordeployment of their protocol, and then for the reality to bedifferent. Furthermore, the full mode provides important securitybenefits. It ensures that an ICE implementation cannot be used tolaunch DoS attacks. Consequently, that same guidance is given here: usingprotocols should only use ICE's lite mode if there is a belief thatimplementors absolutely will not implement the full mode, and thatthose implementations will always be publicly reachable by every otheragent for the lifetime of deployment of that implementation, and thatthe security benefits of full mode are not worth the implementationcomplexity.

4.2. Multiple Components

ICE introduces the concept of multiple components for a single mediastream. ICE attempts to provide atomic processing across components,such that a set of candidates (one for each component) are only usedif all of them succeeded. This grouping is useful when it is desirablefor path characteristics to be identical across multiple IP addressesand ports that make up a connection of some sort.

Using protocols should indicate whether this functionality is neededor not. If not, the procedures defined for ICE are used as is, but theimplementation for the using protocol just assumes there is always asingle component per stream.

4.3. Multiple Media Streams

ICE allows for multiple media streams. ICE largely runs independentlyfor each stream, with a few important exceptions. First, ICE willperform pacing across all of the streams, thus providing aggregatecongestion control. Secondly, ICE will utilize results from one streamto speed up the results of candidate gathering for another stream.

Using protocols should decide whether the concept of multiple streamsapplies or not. If it does, the using protocol can elect to run ICE oneach stream completely independently (in which case its effectively aseparate offer/answer exchange and ICE state machine for each stream),or together. The primary consideration, as noted above, is whetheraggregate congestion control and rapid convergence aredesired. This document recommends that, if a using protocol hasmultiple streams, it runs ICE jointly across them, as defined by theICE specification (in other words, there is one instance of the ICEstate machine, not one for each media stream).

5. ICE Functions

ICE processing can be broken six distinct steps:

1. Gathering of candidates
2. Initial exchange of candidates
3. Connectivity checks
4. Conclusion of ICE
5. Subsequent signaling
6. Media and Keepalives

Each of these steps requires consideration by the designer of theprotocol that intends to use ICE (called the using protocol).

5.1. Gathering of Candidates

This phase of operation involves the gathering of candidates by theagent. Any using protocol will need to perform this step. Thespecification for the using protocol should point to Section 4.1 ofICE, and dictate that the procedures there be followed. However,there are several aspects of the gathering operation which are subjectto considerations by the using protocol, and the using protocol shouldprovide additional guidance on whether any of these behaviors changeor not.

5.1.1. Candidate types

ICE allows an agent, as a matter of policy, to gather candidates of aparticular type - host, server reflexive, and relayed. Consequently, ausing protocol needs to define whether its agents will support allthree, or just a subset. ICE recommends strongly that all three typesbe gathered and supported. This is because reliability of connectionestablishment cannot be provided unless all three mechanisms areimplemented. Using protocols should only utilize a subset if theirdeployment topologies are limited to cases where one of the agentswill always be behind NATs with endpoint independent mappingproperties.

5.1.2. Pacing

ICE defines a pacing algorithm for rate limiting the traffic itgenerates during the gathering phase. When used in conjunction withthe parameter computations in Section 16.2, those algorithms areapplicable to any protocol. However, they may be overly conservativefor certain applications. Consequently, using protocols can definealternative mechanisms for pacing ICE.

However, using protocols should be aware that there are two issuesthat drove the design of the pacing. One of them is network congestioncontrol. The using protocol has to ensure that its pacing remains TCPfriendly whenever possible. The second issue is NAT overload. Testingof NAT devices at the time of writing showed that some of them wentinto an 'overload' mode when too many mappings were created within ashort interval of time. Keeping the creation of new mappings to a rateless than one every 50ms seemed to address this problem. Usingprotocols should follow a similar design goal.

5.1.3. Number and Discovery of Servers

ICE only defines operations for a single STUN server[I‑D.ietf‑behave‑rfc3489bis] (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for (NAT) (STUN),” July 2008.), or for a single TURNserver[I‑D.ietf‑behave‑turn] (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.). It does not considercases where there are multiple STUN and/or multiple TURN servers usedby the agent. However, this is an omission for the sake ofsimplicity. If a using protocol has a need to highly optimize theconnection paths in multi-layer natting environments, multiple STUNservers - ideally one behind each NAT - can provide an optimal path. Ausing protocol can elect to specify that multiple STUN servers be usedin these cases.

Of course, the using protocol will need to specify how a clientdiscovers or is configured with those additional STUN servers. Theusage of multiple STUN servers affects pacing; the overall rate ofcandidate gathering across all servers needs to be congestioncontrolled and stay below the rate of a new allocation every 50ms.

5.1.4. Other Protocols

It is possible that the using protocol can define or utilize othermechanisms for gathering candidates. For example, a mechanism may bebuilt into the rendezvous protocol itself. Indeed, this is the primaryreason for using something besides STUN and TURN. If a using protocolis not building such functionality into the rendezvous server itself,it is highly recommended that it reuse the STUN and TURN protocols.

The primary reason for this is that it allows a domain to deploy STUNand TURN servers just once, and then reuse them for multiple protocolsthat require NAT traversal functionality. This reuse is highlydesirable, and would likely outweigh any minor protocol improvementsthat could come from 'rolling your own' mechanism for gatheringcandidates. This is why an exception is called out for building thegathering protocol into the rendezvous server itself; that serverneeds to be deployed anyway.

However, there are pitfalls to building a candidate gatheringmechanism into the rendezvous protocol and server. In particular,obtaining relayed candidates from a rendezvous protocol can beproblematic. TURN servers are ideally deployed throughout the network,in points that are topologically close to clients. Since the wholepurpose of ICE is to allow two clients to connect directly to eachother without sending data through the rendezvous server, buildingTURN-like functionality into the rendezvous server defeats much of thepurpose of ICE itself. Such a move only makes sense if it is believedthat, for the using protocol, the likelihood of usage of relayedcandidates is particularly low.

5.1.5. Prioritization

ICE allows the prioritization of candidates to be a matter of localpolicy. Using protocols may define their own policy for how candidatesare prioritized. However, protocols absolutely must utilize the samerange of priority values (0 to 2^32 - 1), and must use the concepts offoundations and bases, along with the procedures for eliminatingredundant candidates. Utilizing those ensures that ICE can beinteroperated easily between different using protocols with only agateway function on the signaling, not the media.

5.1.6. Default Candidates

The concept of default candidates is primarily to support backwardscompatibility, and may not be required for a using protocol. Firstly,if a using protocol is being defined for the first time, and ICE isbeing used as a mandatory-to-implement part of the protocol, thenclearly there are no backwards compatibility issues, and the defaultcandidate mechanism is not needed.

Even in cases where there are older, non-ICE implementations, thereare several basic mechanisms that can be used to deal with it:

Capability Query:

An ICE-compliant agent can query the target agent, prior to an ICE exchange, to determine if they support ICE. If they do, the agent proceeds with the ICE exchange, otherwise, they do not. If a using protocol utilizes this basic technique, the default candidate mechanism is not needed.

Fail-and-Retry:

An ICE-compliant agent sends an initial message with ICE parameters, along with some kind of flag which tells the recipient to reject the message if it doesn't support ICE. If such a rejection is received, the agent retries without ICE. If a using protocol utilizes this technique, the default candidate mechanism is not needed.

Fallback:

An ICE-compliant agent sends an initial message with ICE parameters, but they are encoded in such a way that they will be ignored by a non-ICE implementation. If a non-ICE implementation receives them, it sends back an answer without ICE, and the offerer notices this and proceeds without ICE. This technique requires the default candidate mechanism defined by ICE.

Of these three approaches, the first two require potentially two roundtrips to setup a session, whereas the third can do it in a singleround trip regardless of the capabilities of the other agent. When latency for establishment is an important concern, the fallbackapproach is preferable.

5.2. Initial Exchange of Candidates

ICE specifies the usage of the offer/answer protocol and the SessionDescription Protocol for exchanging ICE parameters. This mechanism isclearly ICE specific, and the using protocol should define somethingappropriate. However, in all cases, the protocol exchange has to allowfor a two-phase exchange where one side offers ICE information to theother, and the other offers ICE information back in response. Thoughit is possible for protocols to utilize mechanism other than atwo-phase exchange, this is not recommended, since it significantlycomplicates the construction of gateways between protocols thatutilize ICE.

5.2.1. ICE Mismatch

The ICE mismatch feature is very specific to SIP. It is a consequenceof the existence of intermediaries which routinely modify the mediadestination in the SDP, but are not ICE aware and will just ignore(and pass on) any ICE attributes that are present. The ICE mismatchmechanism detects these cases and falls back to non-ICE operation.

A using protocol should only utilize this mechanism if it happens tohave similar deployment constraints.

5.2.2. Parameter Encoding

The syntax for the messages is entirely a matter of convenience forthe using protocol. However, the following parameters and their datatypes needs to be conveyed in the initial exchange:

Candidate attribute

There will be one or more of these for each "media stream". Each candidate is composed of:

Foundation:

A sequence of up to 32 characters.

Component-ID:

This would be present only if the using protocol were utilizing the concept of components. If it is, it would be a positive integer that indicates the component ID for which this is a candidate.

Transport:

An indicator of the transport protocol for this candidate. This need not be present if the using protocol will only ever run over a single transport protocol. If it runs over more than one, or if others are anticipated to be used in the future, this should be present.

Priority:

An encoding of the 32 bit priority value.

Candidate Type:

The candidate type, as defined in ICE.

Related Address and Port:

The related IP address and port for this candidate, as defined by ICE.

Extensibility Parameters:

The using protocol should define some means for adding new per-candidate ICE parameters in the future.

Lite Flag:

If ICE lite is used by the using protocol, it needs to convey a boolean parameter which indicates whether the implementation is lite or not.

Ufrag and Password:

The using protocol has to convey a username fragment and password. It must allow up to 256 characters for the ufrag and 256 for the password.

ICE extensions:

In addition to the per-candidate extensions above, the using protocol should allow for new media-stream or session-level attributes.

If the using protocol is using the ICE mismatch feature, a way isneeded to convey this parameter in answers. If is a boolean flag.

The exchange of parameters is symmetric; both agents need to send thesame set of attributes as defined above.

The using protocol may (or may not) need to deal with backwardscompatibility with older implementations that do not supportICE. If the fallback mechanism is being used, then presumably theusing protocol already provides a way of conveying the defaultcandidate (its IP address and port) in addition to the ICEparameters.

5.2.3. Role Determination

The role determination mechanism must be used by the usingprotocol. However, the conflict resolution algorithm in Section 5.2 ofICE is almost entirely an artifact of the fact that SIP separates itssignaling exchange from the offer/answer exchange. In using protocols thatlack this separation, the conflict resolution algorithm itself willnever get used.

5.3. Connectivity Checks

The core of the ICE algorithm is the connectivity checks. After bothsides have gathered candidates and have exchanged them with eachother, the check process begins. Here, it is very important that theusing protocol simply follow the mechanisms already defined byICE. Implementations should directly utilize the functionality definedin Section 5.7 to compute pairs and priorities, prune, form the checklists, and compute states. If a using protocol has elected not to usethe concepts of multiple components or multiple streams, thesealgorithms simplify. However, the using protocol must not specify adifferent algorithm; it can only reuse what is there and constrain itsbehavior by mandating constrained inputs (only one component, or onlyone media stream).

The actual connectivity checks themselves must also be performedexactly as defined in Section 7 of ICE. The using protocol should justreference that section directly. Note that, even if a using protocoldoes not need to use the role conflict detection mechanism, it mustinclude the ICE-CONTOLLED and ICE-CONTROLLING attributes in itsconnectivity checks as described in Section 7 of ICE. This ensuresthat it is possible to easily build gateways between differentprotocols using ICE.

5.3.1. Scheduling Checks

The primary area where using protocols can alter the behavior definedin ICE is in the area of pacing. The using protocol can definedifferent mechanisms for computing Ta and RTO, and may even define adifferent mechanism entirely for interleaving scheduled and triggeredchecks.

As with the pacing of candidate gathering, the pacing of connectivitychecks needs to take congestion control and NAT overload intoconsideration.

5.4. Conclusion of ICE

The procedures for concluding ICE as defined in Section 8 should beused as defined for the using protocol, with only a few areas offlexibility.

5.4.1. Regular vs. Aggressive Nomination

The primary area offlexibility is around regular vs. aggressive nomination. A usingprotocol can mandate that all implementations use one or the other orallow for both. The considerations for this choice are identical forthe using protocol as they are for ICE in general. Aggressivenomination is faster but can introduce glitches; regular nomination isslower but is more stable. Regular nomination is recommended if at allpossible.

5.4.2. Updated Signaling and Remote Candidates

ICE defines conditions on which an updated offer is required to besent after ICE concludes - namely, if the candidates selected by ICEare not a match for the default candidates, an updated exchange issent.

This function of ICE is primarily an artifact of the realities of SIPdeployments. It is not at all needed for correctness of ICEoperation. In the case of SIP, signaling intermediaries that areinspecting the offer/answer exchanges, but are not ICE aware, will beconfused unless there is an updated exchange. This same considerationapplies to using protocols. If the using protocol has deployments withintermediaries that inspect messages, and will be confused if theactual connections/media are established to something different thanany defaults that were signaled, the updated exchange should beused. If not, it can be avoided.

If it is used, the remote-candidates attribute has to be conveyed inthe updated offer, and the agents need to implement the algorithmsdescribed in Section 9 of ICE for setting the answer based on thisattribute. Furthermore, the signaling protocols require a way toencode it.

5.5. Subsequent Signaling

ICE defines procedures for performing subequent offer/answer exchangesthat have an affect of updating the state of ICE. Support forsubsequent exchanges is needed if the using protocol requires any ofthe following capabilities:

• The ability to add a new candidate to a set while ICE is already in progress, without abandoning the progress so far.
• The ability to add a new media stream, or remove a new media stream, without redoing ICE processing for all of the media streams.
• The ability to change the IP address or port for a media stream, but to do so with a "make before break" property - so that the new destination begins to be used only once checks for the new destination have completed.

If any of these properties are important, ICE's capabilites forsubsequent signaling should be utilized.

One use case where these functions are not needed is when the usingprotocol fundamentally doesn't allow any kind of updating ofconnection addresses. If it requires the previous connection to beclosed, and a new one to be opened starting from scratch, ICE'ssubsequent signaling feature is not needed.

If subsequent signaling is used, ICE restarts must be supported.

5.6. Media and Keepalives

The keepalive procedures in Section 10 must be used as defined. Themedia handling rules in Section 11 apply as well, with the exceptionof the RTP-specific guidelines.

6. Security Considerations

Several ICE features exist to provide security, including the messageintegrity mechanism. Using protocols must use these in the same wayICE does.

The guidelines defined here do allow a using protocol to support theICE lite mode of operation. The lite mode is less secure than fullmode, as it allows an implementation to be used as a source of DoStraffic. For this reason, using protocols must address, in theirsecurity considerations, why they have elected to allow the liteimplementation in cases where it is being supported.

7. IANA Considerations

There are no IANA considerations associated with this specification.

8. Informative References

Author's Address

Full Copyright Statement

Copyright © 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 providedon an “AS IS” basis and THE CONTRIBUTOR,THE ORGANIZATION HE/SHE REPRESENTSOR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUSTAND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THATTHE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANYIMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULARPURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimedto pertain to the implementation or use of the technologydescribed in this document or the extent to which any licenseunder such rights might or might not be available; nor does itrepresent that it has made any independent effort to identify anysuch rights.Information on the procedures with respect torights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available,or the result of an attempt made to obtain a general license orpermission for the use of such proprietary rights by implementers orusers of this specification can be obtained from the IETF on-line IPRrepository athttp://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attentionany copyrights,patents or patent applications,or otherproprietary rights that may cover technology that may be requiredto implement this standard.Please address the information to the IETF atietf-ipr@ietf.org.

• Info
• Contents
• Prefs