Internet DRAFT - draft-hoerdt-pim-group-unreachable
draft-hoerdt-pim-group-unreachable
Network and Protocol Team M. Hoerdt
Internet-Draft Q2S
Expires: December 11, 2006 B. Hilt
GRTC
J-J. Pansiot
LSIIT
June 9, 2006
Simple join failure notification for PIM-SM multicast routing
draft-hoerdt-pim-group-unreachable-00.txt
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.
This Internet-Draft will expire on December 11, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Currently, PIM-SM is the most widely deployed multicast routing
protocol in the Internet. However in IPv6 this multicast protocol
lacks a simple connectivity debugging tool, making it difficult to
identify multicast routing problems. When a host wants to receive a
multicast group or channel, if the corresponding PIM-Join message
Hoerdt, et al. Expires December 11, 2006 [Page 1]
Internet-Draft Multicast Group Unreachable June 2006
cannot be propagated in the network, nothing exists to inform the
receiver or the network about this failure. We propose a simple
error notification message based on ICMP/ICMP6 which is able to
indicate where and why the error happened in the network without
using a multicast traceroute mechanism.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol description . . . . . . . . . . . . . . . . . . . . . 3
2.1. Sending GU Messages . . . . . . . . . . . . . . . . . . . 4
2.2. Receiving/Forwarding GU Messages . . . . . . . . . . . . . 5
3. Message format . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Type and Code . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. L (The 'Last GU Record' bit) . . . . . . . . . . . . . . . 8
3.4. Reserved1 . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Number of Group Records . . . . . . . . . . . . . . . . . 8
3.6. Router Address . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Group Record . . . . . . . . . . . . . . . . . . . . . . . 9
3.8. Error Code . . . . . . . . . . . . . . . . . . . . . . . . 9
3.9. Reserved2 . . . . . . . . . . . . . . . . . . . . . . . . 9
3.10. Number of Unicast Address . . . . . . . . . . . . . . . . 10
3.11. Multicast Address . . . . . . . . . . . . . . . . . . . . 10
3.12. Unicast Address [i] . . . . . . . . . . . . . . . . . . . 10
4. GU Error codes . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Consideration . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Hoerdt, et al. Expires December 11, 2006 [Page 2]
Internet-Draft Multicast Group Unreachable June 2006
1. Introduction
With the current specification of PIM-SM [1], when a router cannot
propagate a join message, nothing can be done to inform either
receivers or downstream routers. Therefore a useless multicast tree
is maintained from receivers to the point of failure, while receivers
needlessly wait for multicast data. Such a failure may be due for
example to a temporary routing problem (a source or RP is not
currently reachable), a configuration problem (RP adressing, ...) or
a user error (the source address of an SSM channel is not an existing
address).
The basic proposed idea is to send a downstream error message when a
Join message propagation fails at some point in the network. This
may occur towards a source (S) both for a PIM-SM[5] SSM channel or
for a SPT tree for a PIM-SM[1] ASM group; This may also occur between
the DR and the rendez-vous point (RP) for an ASM group. This error
message, later on called Group Unreachable or GU, is carried over the
ICMP/ICMP6[2][3] protocol. This draft specifies:
- the rules used to send and propagate this message down the
multicast tree.
- the ICMP/GU message format.
- the proposed error codes.
The message is forwarded hop-by-hop by routers, it is not sent to the
group address contained in the failing join. The rules to process
this message by multicast hosts is not in the scope of this draft.
This mechanism is simpler than a multicast traceroute but still very
useful. It provides multicast listeners with a report including both
problem location and problem description. It helps network
administrators reporting the problem to the person responsible of the
good operation of multicast routing for the indicated location. The
proposed message could be used by diagnostic applications such as
ssmping or asmping[6] to locate the point of failure in case of
unreachability. Some user applications could also make use of it,
for example to warn the user and/or to leave the corresponding group
or channel. As this mechanism requires to be deployed on all
multicast routers to operate properly, it requires standardisation.
2. Protocol description
When a router R fails to send a Join message towards a rendez-vous
point RP or a source S, it triggers the sending of an ICMP/ICMP6
Group Unreachability (GU) message. GU messages MAY aggregate Join
failure reasons for several unreachable RP(s)/source(s). In order to
locate the point of failure, the GU message contains the address of
R.
Hoerdt, et al. Expires December 11, 2006 [Page 3]
Internet-Draft Multicast Group Unreachable June 2006
To inform all the downstream tree routers and hosts about a failure,
a GU message is propagated hop-by-hop downstream the multicast tree
concerned by the failure (the tree corresponding to the failing Join
message). Along these trees, this information could be taken into
account in order to reduce the cost of useless/problematic multicast
branches. This is beyond the scope of this document.
2.1. Sending GU Messages
GU messages are sent both when a failure occurs on an existing tree
or when a new branch is under construction. In both cases, each
failed Join message triggers the sending of a GU message. If the
failure is due to a transient error such as a temporary routing
problem, the router may choose to suppress the GU message.
On interdomain links and routers, the number of maintained groups/
channels can be high. A single failure on those links may trigger a
high number of GU messages sharing the same point of failure. To
reduce the cost of the protocol in this case, GU messages sent on a
link MAY aggregate unreachability information for several groups/
channels having receivers through this link.
The GU message size is limited to the link MTU. If the number of
groups/channels to aggregate exceeds this size, unreachability
information is fragmented into multiple GU messages. To avoid the
sending of a burst of GU messages, the messages should be rate
limited.
When a multicast router R is unable to send a group/channel Join
message, it builds for each failed group/channel a Group Record
containing its failure information like group/channel identification,
error code, etc... (detailled format in Section 3). For each
outgoing interface of at least one failing tree, the corresponding
Group Records are gathered in the same GU Record.
Then a GU message, possibly aggregating several GU records for this
interface is built. The destination address of the GU messages using
this interface MUST be All_Systems_on_this_Subnet group address
(224.0.0.1) in IPv4, or ALL_NODES_ADDRESS group address (FF02::1) in
IPv6. This ensures that all receivers for the failing group will
received the GU message, together with all PIM Routers on the same
interface. A further study could determine if the use of a specific
multicast address would be more efficient. In this case the
destination address would be All_Multicast_Reception_Hosts group
address (224.0.0.X) in IPv4 and ALL_MULTI_REC_NODES group address
(FF02::X) in IPv6 (X to be defined by IANA).
Hoerdt, et al. Expires December 11, 2006 [Page 4]
Internet-Draft Multicast Group Unreachable June 2006
2.2. Receiving/Forwarding GU Messages
GU messages are forwarded hop-by-hop according to the TIB (Tree
Information Base) maintained by the multicast routing protocol. When
a router R receives a GU message on an interface:
- If the source address of the received message is not the address
of a PIM neighbor for the interface the GU message MUST be
silently ignored.
- If there is no group/channel in the GU message for which the
receiving interface is the incoming interface, the message must be
silently ignored.
The GU message is forwarded on all interested interfaces after a
possible trimming. An interface i is interested by the GU if and
only if the GU contains a group or channel such that:
(1) the GU was received by the incoming interface for this group/
channel
(2) interface i is an outgoing interface for this group/channel. The
GU sent through interface i is trimmed such that it contains only
groups/channels satisfying conditions (1) and (2).
(3) Channel unreachability information (concerned by specific source
S and group G) is only forwarded hop-by-hop down to a shared tree
(*,G) using TIB states if the bit R is set in the GU Record. RP
unreachability information is propagated on the shared (*,G) tree
without setting this bit.
Normally, if a join (S,G) fails the GU is sent only down the (S,G)
tree to the DRs (and eventually to the receivers). In some ASM cases
a join (S,G) may fail between the RP and the FHR. In this case the
GU will travel down to the RP, and if the RP has no outgoing
interface for (S,G), the GU will stop there. The RP may choose to
propagate the GU(S,G) message down the shared tree. If it do so, the
RP MUST take care that this message can be distinguished from regular
GU(S,G) messages. The R bit tells that. Note that such a message
may help debug a problem between the RP and the source, but this
problem may have no direct impact on receivers, if they reach the
source by another route.
This bit is set by the router propagating a GU(S,G) through the
shared tree, and then this GU should be transparently forwarded hop-
by-hop down to the shared tree.
Several GU messages for the same interface, possibly originating from
different routers MAY be aggregated in the same ICMP message.
3. Message format
Hoerdt, et al. Expires December 11, 2006 [Page 5]
Internet-Draft Multicast Group Unreachable June 2006
Join messages sent by a router summarize for a given interface the
group(*,Gn)/channel(Sn,Gn) join state information. These messages
are sent to maintain a connection towards the root of the tree
(Rendez-vous Point or Source). To inform downstream tree members of
a Join propagation failure, each group/channel which cannot be
connected to its tree root will be included into a GU message.
GU messages are a part of ICMP (in IPv4) or ICMP6 (in IPv6) messages.
Over IPv4, GU messages are encapsulated in IPv4 datagrams with a
protocol number of 1. Every GU message is sent with an IP Time-To-
Live of 1. IPv4 GU message MUST only contain unreachability
information about IPv4 addresses.
Over IPv6, GU messages are encapsulated in IPv6 packets with a Next
Header value of 58. An IPv6 GU messages MUST be sent with a link-
local source address, and hop limit set to 1. IPv6 GU message MUST
only contain unreachability information about IPv6 addresses.
A GU message uses the common ICMP/ICMP6 structure. Each ICMP/GU
messages can carry several GU records concerning each an error
location (i.e. router interface). In the following text we use
ICMP/GU to refer to ICMP/GU or ICMP6/GU messages. So, information
specific to a protocol family (IPv4/IPv6) will be specified
explicitely.
A single Group Records informs about a single group address
associated with a single problem notification. GU Records agregate
Group Records with the same failing router address. GU messages
agregate GU Records which MAY come from different router address.
Respective figures 1,2 and 3 explicit the format for GU messages, GU
Records and Group Records.
New Type and Code values must be used to identify new ICMP/ICMP6
Group Unreachability (GU) messages. Type and Code values must be
defined by IANA. This GU header can be common to several GU messages
(until reaching MTU value). Each of them regarding failure on a
specific router.
GU Records on figure 2 have the format presented for 32 bits IPv4
addresses. When using IPv6, all addresses will have a size of 128
bits.
Hoerdt, et al. Expires December 11, 2006 [Page 6]
Internet-Draft Multicast Group Unreachable June 2006
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. GU Record [1] .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. GU Record [2] .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. GU Record [N] .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 : GU Messages format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved1 | Number of Group Records (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Group Record [1] .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Group Record [M] .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 : GU Record format
Hoerdt, et al. Expires December 11, 2006 [Page 7]
Internet-Draft Multicast Group Unreachable June 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|Res|Err Cde| Reserved2 | Number of Unicast Address (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address [1] |
+--- ---+
. . .
+--- ---+
| Unicast Address [N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 : Group Record format
3.1. Type and Code
Identifies the GU messages in the ICMP/ICMP6 messages family.
3.2. Checksum
The checksum is the 16-bit one's complement of the one's complement
sum of the whole ICMP/ICMP6 GU message (the entire IP payload). For
computing the checksum, the Checksum field is set to zero. When
receiving packets, the checksum must be verified before processing
the message.
3.3. L (The 'Last GU Record' bit)
When an ICMP/GU message carries several GU Records, flag L of the
last GU Record MUST be set to 1. All intermediate GU Records MUST
have flag L set to 0. If an ICMP/GU message carries a single GU
Record, flag L of this record MUST be set to 1.
3.4. Reserved1
The Reserved1 field is reserved for future usage. It is set to zero
on emission and ignored on reception.
3.5. Number of Group Records
The Number of Group Records (M) specifies how many Group Records
(information regarding unreachable group/channel) are present in the
GU Record.
Hoerdt, et al. Expires December 11, 2006 [Page 8]
Internet-Draft Multicast Group Unreachable June 2006
3.6. Router Address
The Router Address is used to identify the router on which the Join
message propagation failure occurred. This address should be chosen
among the routers addresses with the largest scope (ie public
addresses for IPv4, global addresses for IPv6 if available).
3.7. Group Record
Each Group Record of a GU Record contains information corresponding
to a group/channel that could not be propagated in a Join message by
the router designated by the Router Address (section Section 3.6).
3.8. Error Code
The four fields R,S,Res,Err Cde (Error Code) pertains to the same
global error code which gives an indication about the type of failure
occuring during the Join message propagation.
3.8.1. R (The 'shaRed' tree bit)
The R bit is set when a GU information triggered by a Join (S,G) must
be propagated in the shared tree. It is typically used to propagated
a failure related to the PIM-SM RP-SPT Switch.
3.8.2. S (The 'Source' or RP bit)
The S bit indicates if the Join error is related to a forwarding
error towards a Rendez-vous Point (S is set to 0) or towards a Source
(S is set to 1).
3.8.3. Res
These two bits are reserved for a future usage. They are set to zero
on emission and ignored on reception.
3.8.4. Error Cde
The Err Cde (Error Code) field is a code that defines a more precise
error type if known. A first list of possible error Code values and
their signification is given in Section 4.
3.9. Reserved2
The Reserved field is reserved for future usage. It is set to zero
on emission and ignored on reception.
Hoerdt, et al. Expires December 11, 2006 [Page 9]
Internet-Draft Multicast Group Unreachable June 2006
3.10. Number of Unicast Address
The Number of Unicast Address (N) field specifies how many unicast
IPv4/IPv6 addresses (RP/Sources) are present in this Group Record.
This allows to determine the size of the current Group Record
3.11. Multicast Address
The Multicast Address field contains the IPv4/IPv6 multicast group
address to which this Group Record pertains.
3.12. Unicast Address [i]
The Unicast Address list is a vector of n IPv4/IPv6 unicast
addresses, where n is the value in this record's Number of Unicast
Addresses (N) field. The unicast addresses are either Rendez-vous
Point or Source addresses depending on the S flag of this record.
If the S bit is set to 0, this error occured in the ASM shared tree
towards the RP. In this case Unicast Address [0] is the RP address
contained in the failing Join message, while Unicast Address [1] is
the RP address known for this group in this router or the NULL
address if there is no local RP information for this group. If the S
bit is set to 1, this error occured in an SSM or an ASM SPT tree.
The list of Unicast Adresses is the list of failing sources for the
same group, usually only one in the SSM case.
4. GU Error codes
The error code indicates the reason of the failure incured by a Join
message forwarded hop-by-hop towards a source (S), if bit S is set or
a Rendez-vous Point (RP), if bit S is cleared. Code values and
signification are proposed in the table below. They are only
suggestions to future definition by IANA.
Hoerdt, et al. Expires December 11, 2006 [Page 10]
Internet-Draft Multicast Group Unreachable June 2006
S | Value | Name | Description
-------------------------------------------------------------------
x | 0x1 | NO_MCAST_IF | The interface pointing to the nexthop
| | | towards the source or the RP is not
| | | enabled for multicast.
---|-------|----------------|--------------------------------------
x | 0x2 | NO_MCAST_NEIGH | The next hop towards the source or
| | | the rendez-vous point is not a
| | | multicast capable neighbor.
---|-------|----------------|--------------------------------------
x | 0x3 | NO_ROUTE | The router has no route for the
| | | source or for the RP of the group.
---|-------|----------------|--------------------------------------
0 | 0x4 | ERR_RP | The router cannot match a proper
| | | Rendez-vous point for the desired
| | | joined groupe. For instance, the RP
| | | mentioned in the (*,G) part
| | | of a Join message may be different
| | | from the local RP information for
| | | that group.
---|-------|----------------|--------------------------------------
x | 0x5 | SCOPED | The group or channel is subject to
| | | administrative scoping at this hop.
---|-------|----------------|--------------------------------------
x | 0x6 | FILTERED | The group or channel is subject to
| | | administrative filtering at this hop.
---|-------|----------------|--------------------------------------
0 | 0x7 | NO_ASM_ADDR | The group address specified in an ASM
| | | Join pertains to a SSM group address
| | | for that router.
---|-------|----------------|--------------------------------------
x | 0xF | NOT_FWD | The router is not forwarding this
| | | group/source for an unspecified
| | | reason.
---|-------|----------------|--------------------------------------
Table 1 : GU error codes
The x value indicates that the error code may be used for both values
of S.
5. Security Consideration
A GU message is an informational message. In this proposal it is
only forwarded by routers and does not interact much more with them.
With this proposal, an important number of non-existent trees could
Hoerdt, et al. Expires December 11, 2006 [Page 11]
Internet-Draft Multicast Group Unreachable June 2006
be joined by a set of malicious hosts in the network, possibly
triggering a storm of GU messages and exausting the ressources
available by trying to signal a malicious error case. This control
plane attack is already possible without the GU message [4]. GU
messages rate limitation MUST be available in order to minimize the
additionnal cost on the network ressources in this kind of attack.
The detailed usage of information carried by the GU message is out of
the scope of this draft but Forged GU messages could be sent in non
failing trees making the receivers believe that the multicast
connection failed at some point in time. To prevent that, only GU
messages from known neighbors SHOULD be accepted by routers
propagating the unreachability information.
6. Acknowledgments
The authors would like to thanks Stig Venaas and Jerome Durand for
the early reviewing and comments on this work.
7. References
7.1. Normative References
[1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", mar 2006.
[2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
[3] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
7.2. Informative References
[4] Savola, P., Lethonen, R., and D. Meyer, "PIM-SM Multicast
Routing Security Issues and Enhancements
(draft-ietf-mboned-mroutesec-04.txt)", oct 2004.
[5] Bhattacharyya, S., "An Overview of Source-Specific Multicast
(SSM)", jul 2003.
[6] Venaas, S., "Source Specific and Any Source multicast ping
(http://www.venaas.no/multicast/ssmping/)", apr 2005.
Hoerdt, et al. Expires December 11, 2006 [Page 12]
Internet-Draft Multicast Group Unreachable June 2006
Authors' Addresses
Mickael Hoerdt
Q2S
E-216 Elektro-E
Q2S Center of Excellence
Trondheim NO-7491
NORWAY
Phone: +47 73 55 02 67
Email: hoerdt@q2s.ntnu.no
URI: http://www.q2s.ntnu.no/~hoerdt/
Benoit Hilt
GRTC
IUT de Colmar
BP 50568
Colmar Cedex 68008
FRANCE
Phone: +33 3 89 20 23 64
Email: benoit.hilt@uha.fr
Jean-Jacques Pansiot
LSIIT Universite Louis Pasteur Strasbourg
Pole API, bureau C447
Boulevard Sebastien Brant
Illkirch 67400
FRANCE
Phone: +33 3 90 24 45 63
Email: pansiot@clarinet.u-strasbg.fr
URI: http://clarinet.u-strasbg.fr/~pansiot/
Hoerdt, et al. Expires December 11, 2006 [Page 13]
Internet-Draft Multicast Group Unreachable June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hoerdt, et al. Expires December 11, 2006 [Page 14]
