Diameter Maintenance and H. Tschofenig
Extensions (DIME) Siemens
Internet-Draft February 27, 2006
Expires: August 31, 2006
Diameter MIPv6 Application for the Integrated Scenario
draft-tschofenig-dime-mip6-integrated-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 August 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A Mobile IPv6 node requires a home agent address, a home address, and
IPsec security association with its home agent before it can start
utilizing Mobile IPv6 service. RFC 3775 requires that some or all of
these parameters are statically configured. Ongoing work aims to
make this information dynamically available to the mobile node. An
important aspect of the Mobile IPv6 bootstrapping solution is to
support interworking with existing authentication, authorization and
accounting infrastructure. This document defines a Diameter
Tschofenig Expires August 31, 2006 [Page 1]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
application to facilitate Mobile IPv6 bootstrapping for the
integrated scenario.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Command Codes and AVPs . . . . . . . . . . . . . . . . . . . . 7
4.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Advertising Application Support . . . . . . . . . . . . . 7
4.3. MIPv6-Bootstrapping-Request (MBR) . . . . . . . . . . . . 8
4.4. MIPv6-Bootstrapping-Answer (MBA) . . . . . . . . . . . . . 8
4.5. MIPv6-Home-Agent-Request (MHR) . . . . . . . . . . . . . . 9
4.6. MIPv6-Home-Agent-Answer (MHA) . . . . . . . . . . . . . . 9
4.7. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7.1. Home Agent Address AVP . . . . . . . . . . . . . . . . 10
4.7.2. Home Agent FQDN AVP . . . . . . . . . . . . . . . . . 10
4.7.3. Home Link Prefix AVP . . . . . . . . . . . . . . . . . 10
4.7.4. Home Address AVP . . . . . . . . . . . . . . . . . . . 10
4.7.5. DNS Update Mobility Option Attribute . . . . . . . . . 10
4.7.6. MIPv6 Bootstrapping Feature Attribute . . . . . . . . 11
4.7.7. MIPv6 Security Association Parameters . . . . . . . . 11
5. Example Exchanges . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Tschofenig Expires August 31, 2006 [Page 2]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
1. Introduction
Mobile IPv6 specification [1] requires a Mobile Node (MN) to perform
registration with a Home Agent with information about its current
point of attachment (Care-of Address). The Home Agent creates and
maintains binding between the MN's Home Address and the MN's Care-of
Address.
In order to register with a Home Agent, the MN needs to know some
information such as, the Home Link prefix, the Home Agent Address,
the Home Address, the Home Link prefix Length and security related
information in order to later secure the Binding Update.
The aforementioned set of information may be statically provisioned
in the MN. However, static provisioning of this information has its
drawbacks. It increases provisioning and network maintenance burden
for the operator. Moreover, static provisioning does not allow load
balancing, failover, opportunistic home link assignment etc. For
example, the user may be accessing the network from a location that
may be geographically far away from the preconfigured home link; the
administrative burden to configure the MN's with the respective
addresses is large and the ability to react on environmental changes
is minimal. In these situations static provisioning may not be
desirable.
Dynamic assignment of Mobile IPv6 home registration information is a
desirable feature for ease of deployment and network maintenance.
For this purpose, the Diameter infrastructure, which is used for
access authentication, can be leveraged to assign some or all of the
necessary parameters. The Diameter server in the Access Service
Provider (ASP) or in the Mobility Service Provider's (MSP) network
may return these parameters to the AAA client. The AAA client might
either be the NAS, in case of the integrated scenario, or the home
agent, in case of the split scenario. The terms integrated and split
are described in the terminology section and were introduced in [2].
Tschofenig Expires August 31, 2006 [Page 3]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
2. Terminology and Abbreviations
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [3].
General mobility terminology can be found in [4]. The following
additional terms, as defined in [2], are used in this document:
Access Service Authorizer (ASA):
A network operator that authenticates a mobile node and
establishes the mobile node's authorization to receive Internet
service.
Access Service Provider (ASP):
A network operator that provides direct IP packet forwarding to
and from the mobile node.
Mobility Service Authorizer (MSA):
A service provider that authorizes Mobile IPv6 service.
Mobility Service Provider (MSP):
A service provider that provides Mobile IPv6 service. In order to
obtain such service, the mobile node must be authenticated and
authorized to obtain the Mobile IPv6 service.
Split scenario:
A scenario where the mobility service and the network access
service are authorized by different entities.
Integrated Scenario:
A scenario where the mobility service and the network access
service are authorized by the same entity.
Tschofenig Expires August 31, 2006 [Page 4]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
3. Overview
This document addresses the authentication, authorization and
accounting functionality required by for the MIPv6 bootstrapping as
outlined in the MIPv6 bootstrapping problem statement document (see
[2]). This document focuses on the AAA functionality for the
integrated scenario. The AAA interaction for the split scenario seem
to be much simpler and described in [10].
The subsequent text outlines the AAA interaction between the
participating entities in the integrated scenario. In the integrated
scenario MIPv6 bootstrapping is provided as part of the network
access authentication procedure. Figure 1 shows the participating
entities.
+---------------------------+ +-----------------+
|Access Service Provider | |ASA/MSA/(/MSP) |
|(Mobility Service Provider)| | |
| | | |
| +--------+ | | +--------+ |
| |Local | Diameter | | |Home | |
| |Diameter|<----------------------> Diameter| |
| |Proxy | | | |Server | |
| +--------+ | | +--------+ |
| ^ | | ^ |
| | | |Diameter| |
| | | | | |
| |Diameter | | v |
| | +-------+ | | +-------+ |
| | Diameter |Home | | | |Home | |
| | +------->|Agent | | | |Agent | |
| | | |in ASP | | | | | |
| v v +-------+ | | +-------+ |
+-------+ IEEE | +-----------+ +-------+ | +-----------------+
|Mobile | 802.1X | |NAS/Relay | |DHCPv6 | |
|Node |----------+-|Diameter |---|Server | |
| | PANA,... | |Client | | | |
+-------+ DHCP | +-----------+ +-------+ |
+---------------------------+
Figure 1: Mobile IPv6 Bootstrapping: Integrated scenario
In the typical Mobile IPv6 access scenario as shown above, the MN
attaches in a Access Service Provider's network. During this network
attachment procedure, the NAS/Diameter client interacts with the
mobile node. As shown in Figure 1, the authentication and
authorization happens via a Diameter infrastructure.
Tschofenig Expires August 31, 2006 [Page 5]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
At the time of authorizing the user for IPv6 access, the Diameter
server in the MSA detects that the user is authorized for Mobile IPv6
access. Based on the MSA's policy, the Diameter server may allocate
several parameters to the MN for use during the subsequent Mobile
IPv6 protocol interaction with the home agent.
Depending on the details of the solution interaction with the DHCPv6
server may be required, as described in [5].
Tschofenig Expires August 31, 2006 [Page 6]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
4. Command Codes and AVPs
This section defines command codes and AVPs for usage of Diameter for
bootstrapping MIPv6 in the split scenario.
4.1. Command Codes
This document introduces four new command codes:
o MIPv6-Bootstrapping-Request (MBR) (Code TBD)
o MIPv6-Bootstrapping-Answer (MBA) (Code TBD)
o MIPv6-Home-Agent-Request (MHR) (Code TBD)
o MIPv6-Home-Agent-Answer (MHA) (Code TBD)
In addition, the following Diameter Base protocol messages are used
with this application:
Command-Name Abbrev. Code Reference
Accounting-Request ACR 271 RFC 3588
Accounting-Request ACR 271 RFC 3588
Accounting-Answer ACA 271 RFC 3588
Re-Auth-Request RAR 258 RFC 3588
Re-Auth-Answer RAA 258 RFC 3588
Abort-Session-Request ASR 274 RFC 3588
Abort-Session-Answer ASA 274 RFC 3588
Session-Term-Request STR 275 RFC 3588
Session-Term-Answer STA 275 RFC 3588
4.2. Advertising Application Support
Diameter nodes conforming to this specification MAY advertise support
by including the value of (TBD) in the Auth-Application-Id or the
Acct-Application-Id AVP of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer command [6].
The value of TBD MUST be used as the Application-Id in all MBR/MBA
and MHR/MHA commands.
The value of zero (0) SHOULD be used as the Application-Id in all
STR/STA, ACR/ACA, ASR/ASA, and RAR/RAA commands, because these
commands are defined in the Diameter base protocol and no additional
mandatory AVPs for those commands are defined in this document.
Tschofenig Expires August 31, 2006 [Page 7]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
4.3. MIPv6-Bootstrapping-Request (MBR)
The MIPv6-Bootstrapping-Request message (MBR) indicated by the
Command- Code field (see Section 3 of [6]) set to TBD and 'R' bit set
in the Command Flags field is used by Diameter clients to request
home agent assignment, to authorize for mobility service usage and
optionally to indicate the support of local home agent assignment.
The MBR message MAY carry the DNS Update Mobility Option and the
MIPv6 Bootstrapping Feature attribute.
The message format, presented in ABNF form [7], is defined as
follows:
<MIPv6-Bootstrapping-Request> ::= < Diameter Header: XXX, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ User-Name ]
[ DNS Update Mobility Option ]
[ MIPv6 Bootstrapping Feature ]
* [ AVP ]
4.4. MIPv6-Bootstrapping-Answer (MBA)
The MIPv6-Bootstrapping-Answer (MBA) message, indicated by the
Command- Code field set to TBD and 'R' bit cleared in the Command
Flags field is sent in response to the MIPv6-Bootstrapping-Request
message (MBR). If the mobility service is successfully authorized
and the Diameter server was able to fulfill the bootstrapping request
(if needed) then the response MAY include the DNS Update Mobility
Option, Home Address, Home Link Prefix, Home Agent FQDN and the Home
Agent Address AVP.
The message format is defined as follows:
Tschofenig Expires August 31, 2006 [Page 8]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
<MIPv6-Bootstrapping-Answer> ::= < Diameter Header: XXX, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ DNS Update Mobility Option ]
[ Home Address ]
[ Home Link Prefix ]
[ Home Agent FQDN ]
[ Home Agent Address ]
* [ AVP ]
4.5. MIPv6-Home-Agent-Request (MHR)
The MIPv6-Home-Agent-Request (MHR) message, indicated by the Command-
Code field set to TDB and 'R' bit set in the Command Flags field is
used by Diameter entity (acting as a Diameter client) to interact
with the home agent. (acting as a Diameter server).
The message MUST carry the MIPv6 Security Association Parameters.
Additionally, the Diameter client might provide the Home Address and
the Home Link Prefix to the Diameter server.
The message format is defined as follows:
<MIPv6-Home-Agent-Request> ::= < Diameter Header: XXX, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ Home Address ]
[ Home Link Prefix ]
[ MIPv6 Security Association ]
* [ AVP ]
4.6. MIPv6-Home-Agent-Answer (MHA)
The MIPv6-Home-Agent-Answer (MHA) message, indicated by the Command-
Code field set to TBD and 'R' bit cleared in the Command Flags field
is sent in response to the MIPv6-Home-Agent-Request (MHR) message for
confirmation of the result of MIPv6 HA bootstrapping. This message
MAY contain the Home Link Prefix and the Home Address.
Tschofenig Expires August 31, 2006 [Page 9]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
The message format is defined as follows:
<MIPv6-Home-Agent-Answer (MHA)> ::= < Diameter Header: XXX, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
[ Home Address ]
[ Home Link Prefix ]
* [ AVP ]
4.7. AVPs
4.7.1. Home Agent Address AVP
The Diameter server MAY decide to assign a Home Agent to the MN that
is in close proximity to the point of attachment (e.g., determined by
the NAS-ID). There may be other reasons for dynamically assigning
Home Agents to the MN, for example to share the traffic load. The
AVP also contains the prefix length so that the MN can easily infer
the Home Link prefix from the Home Agent address.
4.7.2. Home Agent FQDN AVP
The Diameter server MAY assign an FQDN of the home address to the MN.
The mobile node can perform DNS query with the FQDN to derive the
home agent address.
4.7.3. Home Link Prefix AVP
For the same reason as the HA assignment, the Diameter server MAY
assign a Home Link that is in close proximity to the point of
attachment (NAS-ID). The MN can perform [1] specific procedures to
discover other information for Mobile IPv6 registration.
4.7.4. Home Address AVP
The Diameter server MAY assign a Home Address to the MN. This allows
the network operator to support mobile devices that are not
configured with static addresses. The attribute also contains the
prefix length so that the MN can easily infer the Home Link prefix
from the Home Agent address.
4.7.5. DNS Update Mobility Option Attribute
By using this payload the Diameter client instructs the Diameter
Tschofenig Expires August 31, 2006 [Page 10]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
server to perform a dynamic DNS update. When this payload is
included in the reverse direction, i.e., from the Diameter server to
the Diameter client, it informs about the status of the dynamic DNS
update. When the payload is sent from the Diameter client to the
Diameter server then the response MUST include the DNS Update
Mobility Option AVP.
4.7.6. MIPv6 Bootstrapping Feature Attribute
By using this payload the Diameter client indicates to the Diameter
server certain capabilities and features. For example, the Diameter
client might want to indicate that local Home Agent assignment can be
provided.
Local-Home-Agent-Assignment:
This flag is set to 1 when the Diameter client knows that a local
home agent can be provided for the mobile node. Whether a local
home agent can be provided depends on the functionality offered by
the visited network and configured to the Diameter client.
4.7.7. MIPv6 Security Association Parameters
This payload is used by the Diameter entity to provision keying
material in a push fashion to the home agent. This AVP includes
keying material, lifetime and key name information. Security
parameter bootstrapping can be provided for IKEv2 [8], IKEv1 or for
the MIPv6-AUTH protocol.
[Editor's Note: A future version of this document will provide
detailed AVP formats.]
Tschofenig Expires August 31, 2006 [Page 11]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
5. Example Exchanges
The following section shows a basic message flow with dynamic Home
Agent assignment in the user's home network. The MBR / MBA message
exchange illustrates the communication between the Diameter client
and the Diameter server to initiate the bootstrapping procedure. The
interaction between the Home Diameter server and the Home Agent (for
HA bootstrapping in the home network) is depicted with the MHR / MHA
exchange.
Visited Diameter Home Diameter
Mobile Node Diameter Client Proxy AAAh Server Home Agent
----------- ----------- ------------ ---------- ----------
initiate network
access (1)
(2) MBR------------->
(3) MBR------------>
(4) MHR------->
<------(5) MHA
<---------(6) MBA
<------------(7) MBA
Figure 7: Basic Boostrapping Scenario
[Editor's Note: A future version of this document will provide
additional examples.]
Tschofenig Expires August 31, 2006 [Page 12]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
6. Security Considerations
The security considerations for the Diameter interaction required to
accomplish the integrated scenario are described in [5] .
Additionally, the security consideratios of the Diameter base
protocol [6], Diameter NASREQ [11] / Diameter EAP [12] (with respect
to network access authentication and the transport of keying
material) are applicable to this document.
Tschofenig Expires August 31, 2006 [Page 13]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
7. Acknowledgements
This document is heavily based on the ongoing work for RADIUS MIPv6
interaction. Hence, credits go to Kuntal Chowdhury and Avi Lior for
their work with draft-chowdhury-mip6-radius-00.txt. Furthermore, the
author would like to thank the authors of
draft-le-aaa-diameter-mobileipv6-04.txt (Franck Le, Basavaraj Patil,
Charles E. Perkins, Stefano Faccin) for their work in context of
MIPv6 Diameter interworking. Their work influenced this document.
Parts of this document are a byproduct of the ENABLE Project,
partially funded by the European Commission under its Sixth Framework
Programme. It is provided "as is" and without any express or implied
warranties, including, without limitation, the implied warranties of
fitness for a particular purpose. The views and conclusions
contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the ENABLE Project or
the European Commission.
Tschofenig Expires August 31, 2006 [Page 14]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
8. Contributors
Add your name here.
Tschofenig Expires August 31, 2006 [Page 15]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
9. Open Issues
A number of open issues have been identified during the work on this
document. This document is incomplete since the AAA interaction for
MIPv6 bootstrapping is still at an early stage. The following
aspects require further discussion:
o The details of the Diameter bootstrapping with respect to
security.
o AVP formats are not yet provided and a table of occurance is
missing.
o The IANA consideration section is empty.
o Diameter Client/Server Behavior needs to be specified explicitly.
o More examples are useful.
o Alignment with the ongoing RADIUS MIPv6 bootstrapping needs to be
ensured.
Tschofenig Expires August 31, 2006 [Page 16]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
10. References
10.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping
Mobile IPv6", draft-ietf-mip6-bootstrap-ps-04 (work in
progress), February 2006.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
[4] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[5] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in
progress), October 2005.
[6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[8] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with IKEv2
and the revised IPsec", draft-ietf-mip6-ikev2-ipsec-04 (work in
progress), October 2005.
[9] Giaretta, G., "Goals for AAA-HA interface",
draft-ietf-mip6-aaa-ha-goals-01 (work in progress),
January 2006.
10.2. Informative References
[10] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter",
draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress),
October 2005.
[11] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005.
[12] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
Tschofenig Expires August 31, 2006 [Page 17]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
[13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-01 (work in progress),
October 2005.
[14] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[15] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Tschofenig Expires August 31, 2006 [Page 18]
Internet-Draft Diameter MIPv6 Integrated Scenario February 2006
Author's Address
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Tschofenig Expires August 31, 2006 [Page 19]
Internet-Draft Diameter MIPv6 Integrated Scenario February 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.
Tschofenig Expires August 31, 2006 [Page 20]