--- 1/draft-ietf-mboned-ssmping-07.txt 2010-03-04 23:11:06.000000000 +0100 +++ 2/draft-ietf-mboned-ssmping-08.txt 2010-03-04 23:11:06.000000000 +0100 @@ -1,103 +1,163 @@ Network Working Group S. Venaas Internet-Draft UNINETT -Intended status: Standards Track December 2, 2008 -Expires: June 5, 2009 +Intended status: Standards Track March 4, 2010 +Expires: September 5, 2010 Multicast Ping Protocol - draft-ietf-mboned-ssmping-07 + draft-ietf-mboned-ssmping-08.txt + +Abstract + + The Multicast Ping Protocol specified in this document allows for + checking whether an endpoint can receive multicast, both Source- + Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also + be used to obtain additional multicast-related information such as + multicast tree setup time. This protocol is based on an + implementation of tools called ssmping and asmping. + +Requirements Language + + 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]. 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. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and 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. - This Internet-Draft will expire on June 5, 2009. - -Abstract - - The Multicast Ping Protocol specified in this document allows for - checking whether an endpoint can receive multicast, both Source- - Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also - be used to obtain additional multicast-related information such as - multicast tree setup time. This protocol is based on an - implementation of tools called ssmping and asmping. + This Internet-Draft will expire on September 5, 2010. -Requirements Language +Copyright Notice + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. - 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 [1]. + 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 + 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5 - 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6 - 3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 11 - 3.4. Message Types and Options . . . . . . . . . . . . . . . . 11 - 3.5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 13 - 4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14 - 5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 15 - 6. Recommendations for Implementers . . . . . . . . . . . . . . . 16 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 - Intellectual Property and Copyright Statements . . . . . . . . . . 21 + 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 7 + 3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 12 + 3.4. Message Types and Options . . . . . . . . . . . . . . . . 13 + 3.5. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 14 + 4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 15 + 5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 16 + 6. Recommendations for Implementers . . . . . . . . . . . . . . . 17 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction The Multicast Ping Protocol specified in this document allows for checking multicast connectivity. In addition to checking reception of multicast (SSM or ASM), the protocol can provide related information such as multicast tree setup time, the number of hops the packets have traveled, as well as packet delay and loss. This functionality resembles, in part, the ICMP Echo Request/Reply - mechanism [2], but uses UDP [3] and requires both a client and a - server implementing this protocol. Intermediate routers are not - required to support this protocol. They forward Protocol Messages - and data traffic as usual. + mechanism [RFC0792], but uses UDP [RFC0768] and requires both a + client and a server implementing this protocol. Intermediate routers + are not required to support this protocol. They forward Protocol + Messages and data traffic as usual. This protocol is based on the current implementation of the ssmping - and asmping tools [5] which are widely used by the Internet community - to conduct multicast connectivity tests. + and asmping tools [impl] which are widely used by the Internet + community to conduct multicast connectivity tests. 2. Architecture Before describing the protocol in detail, we provide a brief overview of how the protocol may be used and what information it may provide. + The protocol is used between clients and servers. A server may be + configured with a set of ranges of multicast addresses that can be + used for testing, or it may use some implementation defaults. + Depending on the server configuration or the implementation it may + control which clients (which unicast addresses) are allowed to use + different group ranges, and also whether clients can select a group + address, or if the group address is selected by the server. It also + depends on configuration and/or implementation whether several + clients are allowed to simultaneously use the same multicast address. + + In addition to the above state, a server normally has runtime soft + state. The server must generally perform rate limiting to restrict + the number of client requests it handles. This rate limiting is per + client IP address. This state need only be maintained for a few + seconds (normally to have an average rate of maximum one request per + second). If the server provides unique multicast addresses to + clients, it must also have soft state tracking which multicast + addresses are used by which client IP address. This state should + expire if the server has not received requests within a few minutes. + The exact timeout should ideally be configurable to cope with + different environments. If a client is expected to perform multicast + ping checks continuously for a long period of time, and to cope with + requests not reaching the client for several minutes, then this + timeout needs to be extended. In order to verify the client IP + address, the server should perform a return routability check by + giving the client a non-predictable session ID. This would then also + be part of the server soft-state for that client. + + A client must before it can perform a multicast ping test, know the + unicast address of a server. In addition it may be configured with a + multicast address or range to use. In that case the client will tell + the server which group or range it wishes to use. If not, the server + is left to decide the group. Normally a client sends one request per + second. It may however be configured to use another rate. + + At runtime, a client generates a client ID that is unique for the + ping test. This ID is included in all messages sent by the client. + Further, if not supplied with a specific group address, the client + will receive a group address from the server, that is used for the + ping requests. It may also receive a Session ID from the server. + The client ID, group address and Session ID (if received) will then + be fixed for all ping requests in this session. When a client + receives replies from a server, it will verify the client ID in the + reply, and ignore it if not matching what it used in the requests. + For each reply it may print or record information like round trip + time, number of hops etc. The client may once a ping session is + ended, calculate and print or record statistics based on the entire + ping session. + The typical protocol usage is as follows: A server runs continuously to serve requests from clients. A client has somehow learned the unicast address of the server and tests the multicast reception from the server. The client application will then send a unicast message to the server asking for a group to use. Optionally a user may request a specific group or scope, in which case the client will ask for a group matching the user's request. The server will respond with a @@ -184,29 +244,31 @@ The Init message generally contains some prefix options asking the server for a group from one of the specified prefixes. The server responds with a Server Response message that contains the group address to use, or possibly prefix options describing what multicast groups the server may be able to provide. For an Echo Request the client generally includes a number of options, and a server MAY simply echo the contents (only changing the message type) without inspecting the options if it does not support any options. This might be true for a simple Multicast Ping Protocol - server. However, the server SHOULD add a TTL option, and there are - other options that a server implementation MAY support, e.g., the - client may ask for certain information or a specific behaviour from - the server. The Echo Replies (one unicast and one multicast) MUST - first contain the exact options (excluding the Session ID option) - from the request (in the same order), and then, immediately - following, any options appended by the server. A server MUST NOT - process unknown options, but they MUST still be included in the Echo - Reply. A client MUST ignore any unknown options. + server, but it severly limits what information a client can obtain, + and hence makes the protocol less useful. However, the server SHOULD + add a TTL option (allowing the client to determine the number of + router hops a reply has traversed), and there are other options that + a server implementation MAY support, e.g., the client may ask for + certain information or a specific behaviour from the server. The + Echo Replies (one unicast and one multicast) MUST first contain the + exact options from the request (in the same order), and then, + immediately following, any options appended by the server. A server + MUST NOT process unknown options, but they MUST still be included in + the Echo Reply. A client MUST ignore any unknown options. The size of the protocol messages is generally smaller than the Path MTU and fragmentation is not a concern. There may however be cases where the Path MTU is really small, or that a client sends large requests in order to verify that it can receive fragmented multicast datagrams. This document does not specify whether Path MTU Discovery should be performed, etc. A possible extension could be an option where a client requests Path MTU Discovery and receives the current Path MTU from the server. @@ -257,61 +319,67 @@ Version, type 0 Length MUST be 1. This option MUST always be included in all messages, and for the current specified protocol this value MUST be set to 2 (in decimal). Note that there are implementations of older revisions of this protocol that only partly follow this specification. They can be regarded as version 1 and do not use this option. If a server receives a message with a version other than 2 (or missing), the server SHOULD (unless it supports the particular version) send a - Server Response message back with version set to 2. Client ID - and Sequence Number options SHOULD be echoed if present. The - server SHOULD NOT include any other options. A client - receiving a response with a version other than 2 MUST stop - sending requests to the server (unless it supports the - particular version). + Server Response message back with version set to 2. This tells + the client that the server expects version 2 messages. Client + ID and Sequence Number options SHOULD be echoed if present, so + that a client can be certain it is a response to one of its + messages, and exactly which message. The server SHOULD NOT + include any other options. A client receiving a response with + a version other than 2 MUST stop sending requests to the server + (unless it supports the particular version). Client ID, type 1 Length MUST be non-zero. A client SHOULD always include this option in all messages (both Init and Echo Request). The client may use any value it likes to detect whether a reply is a reply to its Init/Echo Request or not. A server should treat this as opaque data, and MUST echo this option back in the reply if present (both Server Response and Echo Reply). The - value might be a process ID, perhaps process ID combined with - an IP address because it may receive multicast responses to - queries from other clients. It is left to the client - implementer how to use this option. + value might be a randomised string that is likely to be unique, + possibly combined with the client IP address. This is used by + the client to ensure that server messages are in response to + its requests. In some cases a client may receive multicast + responses to queries from other clients. It is left to the + client implementer how to use this option. Sequence Number, type 2 Length MUST be 4. A client MUST always include this in Echo Request messages and MUST NOT include it in Init messages. A server replying to an Echo Request message MUST copy it into the Echo Reply (or Server Response message on error). The sequence number is a 32-bit integer. Values typically start at 1 and increase by one for each Echo Request in a sequence. Client Timestamp, type 3 Length MUST be 8 bytes. A client SHOULD include this in Echo Request messages and MUST NOT include it in Init messages. A server replying to an Echo Request message MUST copy it into the Echo Reply. The timestamp specifies the time when the Echo Request message is sent. The first 4 bytes specify the number of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 bytes specify the number of microseconds since the second - specified in the first 4 bytes. + specified in the first 4 bytes. This option would typically be + used by a client to compute round trip times. Multicast Group, type 4 + Length MUST be greater than 2. It MAY be used in Server Response messages to tell the client what group to use in subsequent Echo Request messages. It MUST be used in Echo Request messages to tell the server what group address to respond to (this group would typically be previously obtained in a Server Response message). It MUST be used in Echo Reply messages (copied from the Echo Request message). It MUST NOT be used in Init messages. The format of the option value is as below. @@ -315,23 +383,23 @@ be used in Init messages. The format of the option value is as below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Multicast group address... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | The address family is a value 0-65535 as assigned by IANA for - Internet address families [4]. This is followed by the group - address. Length of the option value will be 6 for IPv4, and 18 - for IPv6. + Internet address families [addrfamily]. This is followed by + the group address. Length of the option value will be 6 for + IPv4, and 18 for IPv6. Option Request Option, type 5 Length MUST be greater than 1. This option MAY be used in client messages (Init and Echo Request messages). A server MUST NOT send this option, except that if it is present in an Echo Request message, the server MUST echo it in replies (Echo Reply message) to the Echo Request. This option contains a list of option types for options that the client is requesting from the server. Support for this option is optional for both @@ -365,21 +433,25 @@ Length MUST be non-zero. It MAY be used in Server Response messages and MUST NOT be used in other messages. Support for this option is optional. A server supporting this option SHOULD add it in Server Response messages if and only if requested by the client. The value is a UTF-8 string that might contain vendor and version information for the server implementation. It may also contain information on which options the server supports. An interactive client MAY support this option, and SHOULD then allow a user to request this - string and display it. + string and display it. Although support for this is optional, + we say that a server SHOULD return it if requested, since this + may be helpful to a user running the client. It is however + purely informational, it is not needed for the protocol to + function. Reserved, type 7 This option code value was used by early implementations for an option that is now deprecated. This option should no longer be used. Clients MUST NOT use this option. Servers MUST treat it as an unknown option (not process it if received, but if received in an Echo Request message, it MUST be echoed in the Echo Reply message). @@ -397,73 +469,78 @@ Length MUST be 1. This option contains a single octet specifying the TTL of an Echo Reply message. Every time a server sends a unicast or multicast Echo Reply message, it SHOULD include this option specifying the TTL. This is used by clients to determine the number of hops the messages have traversed. It MUST NOT be used in other messages. A server SHOULD specify this option if it knows what the TTL of the Echo Reply will be. In general the server can specify a specific TTL to the host stack. Note that the TTL is not necessarily the same for unicast and multicast. Also note that this option - SHOULD be included even when not requested by the client. + SHOULD be included even when not requested by the client. The + protocol will work even if this option is not included, but it + limits what information a client can obtain. Multicast Prefix, type 10 Length MUST be greater than 2. It MAY be used in Init messages to request a group within the prefix(es) and it MAY be used in Server Response messages to tell the client what prefix(es) it may try to obtain a group from. It MUST NOT be used in Echo Request/Reply messages. Note that this option MAY be included multiple times to specify multiple prefixes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Prefix Length |Partial address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... | The address family is a value 0-65535 as assigned by IANA for - Internet address families [4]. This is followed by a prefix - length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special - "wildcard" use discussed below), and finally a group address. - For any family, prefix length 0 means that any multicast - address from that family is acceptable. This is what we call - "wildcard." The group address need only contain enough octets - to cover the prefix length bits (i.e., the group address would - have to be 3 octets long if the prefix length is 17-24, and - there need be no group address for the wildcard with prefix + Internet address families [addrfamily]. This is followed by a + prefix length (4-32 for IPv4, 8-128 for IPv6, or 0 for the + special "wildcard" use discussed below), and finally a group + address. For any family, prefix length 0 means that any + multicast address from that family is acceptable. This is what + we call "wildcard." The group address need only contain enough + octets to cover the prefix length bits (i.e., the group address + would have to be 3 octets long if the prefix length is 17-24, + and there need be no group address for the wildcard with prefix length 0). Any bits past the prefix length MUST be ignored. For IPv4, the option value length will be 4-7, while for IPv6, it will be 4-19, and for the wildcard, it will be 3. Session ID, type 11 - Length MUST be non-zero. A server SHOULD include this in Server Response messages. If a client receives this option in a message, the client MUST echo the Session ID option in subsequent Echo Request messages, with the exact same value. The Session ID may help the server in keeping track of clients and possibly manage per client state. The value of a new Session ID SHOULD be chosen pseudo randomly so that it is hard to predict. The Session ID can be used to prevent spoofing of - the source address of Echo Request messages. See the Security - Considerations for details. + the source address of Echo Request messages. We say that this + option SHOULD be used, because it is important for security + reasons. There may however be environments where this is not + required. See the Security Considerations for details. Server Timestamp, type 12 Length MUST be 8 bytes. A server supporting this option, SHOULD include it in Echo Reply messages, if requested by the client. The timestamp specifies the time when the Echo Reply message is sent. The first 4 bytes specify the number of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 bytes specify the number of microseconds since the second - specified in the first 4 bytes. + specified in the first 4 bytes. If this option is not + included, the protocol will still work, but it makes it + impossible for a client to compute one way delay. 3.3. Packet Format The format of all messages is a one octet message type, followed by a variable number of options. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Options ... | @@ -555,42 +632,42 @@ TTL (9) | NOT | NOT | NOT | SHOULD | Multicast Prefix (10) | MAY | MAY | NOT | NOT | Session ID (11) | NOT | SHOULD | ECHO | NOT | Server Timestamp (12) | NOT | NOT | NOT | RQ | -----------------------+--------+----------+---------+--------+ NOT means that the option MUST NOT be included. ECHO for a server means that if the option is specified by the client, then the server MUST echo the option in the response, with the exact same option value. ECHO for a client only applies to the Session ID option. If - it is present in the Server Response, then it must be present with + it is present in the Server Response, then it MUST be present with the exact same option value in the following Echo Requests. RQ means that the server SHOULD include the option in the response, when requested by the client using the Option Request option. 3.5. Rate Limiting Clients MUST by default send at most one Echo Request per second. Servers MUST by default perform rate limiting, to guard against this protocol being used for DoS attacks. The server MUST by default for a given client, respond to on average at most one Echo Request message per second. Server implementations should provide configuration options allowing certain clients to perform more rapid Echo Requests. If higher rates are allowed for specific client IP addresses, then Init messages and the Session ID option MUST be used to help prevent spoofing. Implementers of applications/tools using this protocol SHOULD - consider the UDP guidelines [6], in particular if clients are to - send, or servers are to accept, Echo Requests at rates exceeding one - per second. See Section 9, "Security Considerations", for additional - discussion. + consider the UDP guidelines [RFC5405], in particular if clients are + to send, or servers are to accept, Echo Requests at rates exceeding + one per second. See Section 9, "Security Considerations", for + additional discussion. 4. Client Behaviour We will consider how a typical interactive client using the above protocol would behave. A client only requires a user to specify the unicast address of the server. It can then send an Init message with a prefix option containing the desired address family and zero prefix length (wildcard entry). The server can then decide which group, from the @@ -725,21 +802,21 @@ specification in Section 3.5. 7. Acknowledgments The ssmping concept was proposed by Pavan Namburi, Kamil Sarac and Kevin C. Almeroth in the paper SSM-Ping: A Ping Utility for Source Specific Multicast, and also the Internet Draft draft-sarac-mping-00.txt. Mickael Hoerdt has contributed with several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb and Dave Thaler have contributed in different ways to the implementation of - the ssmping tools at [5]. Many people in communities like TERENA, + the ssmping tools at [impl]. Many people in communities like TERENA, Internet2 and the M6Bone have used early implementations of ssmping and provided feedback that have influenced the current protocol. Thanks to Kevin Almeroth, Tony Ballardie, Bill Cerveny, Toerless Eckert, Marshall Eubanks, Gorry Fairhurst, Alfred Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, Trond Skjesol and Cao Wei for reviewing and providing feedback on this draft. In particular Hugo, Gorry and Bharat have provided lots of input on several revisions of the draft. 8. IANA Considerations @@ -829,78 +906,40 @@ to send an Init message, and return an unpredictable Session ID in the response. The ID should be associated with the IP address and have a limited lifetime. The server SHOULD then only respond to Echo Request messages that have a valid Session ID associated with the source IP address of the Echo Request. 10. References 10.1. Normative References - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. - [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, - September 1981. + [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, September 1981. - [3] Postel, J., "User Datagram Protocol", STD 6, RFC 768, - August 1980. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. - [4] "IANA, Address Family Numbers", + [addrfamily] + "IANA, Address Family Numbers", . 10.2. Informative References - [5] "ssmping implementation", - . + [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines + for Application Designers", BCP 145, RFC 5405, + November 2008. - [6] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for - Application Designers", BCP 145, RFC 5405, November 2008. + [impl] "ssmping implementation", + . Author's Address Stig Venaas UNINETT Trondheim NO-7465 Norway Email: venaas@uninett.no - -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 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. - -Intellectual Property - - 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.