One document matched: draft-xia-netlmm-radius-00.txt
Network Working Group F. Xia
Internet-Draft B. Sarikaya
Expires: January 2, 2008 Huawei USA
July 2007
RADIUS Proxy Mobile IPv6
draft-xia-netlmm-radius-00
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 January 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Xia & Sarikaya Expires January 2, 2008 [Page 1]
Internet-Draft RADIUS-PMIP6 July 2007
Abstract
Proxy Mobile IPv6 is network based mobility management protocol which
allows IP session continuity for a mobile node without its
involvement in mobility management. A mobile access gateway (MAG) is
authorized to send Mobile IPv6 signaling messages on behalf of mobile
nodes. The MAG requires a local mobility anchor address(LMAA),
mobile node's identifier (MN-Identifier),and IPsec security
association (SA) with it's LMA before it sends signaling messages.
Interworking with existing authentication, authorization and
accounting (AAA) infrastructure, MAG acquires the LMAA (directly or
indirectly) and MN-Identifier. LMA also uses AAA infrastructure to
authenticate MAG and build SA between MAG when EAP is used with
IKEv2. This document defines new RADIUS attributes and reasonably
reuses existing attributes to serve the purpose. This information
exchange takes place as part of the initial network access
authentication procedure. Address configuration modes and others can
also be obtained from AAA infrastructure to emulate MN's home link on
access links.
Xia & Sarikaya Expires January 2, 2008 [Page 2]
Internet-Draft RADIUS-PMIP6 July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MIP6 Bootstrapping Overview . . . . . . . . . . . . . . . 5
3.2. PMIP6 Bootstrapping Procedure . . . . . . . . . . . . . . 6
3.2.1. Security Association Setup . . . . . . . . . . . . . . 6
3.2.2. Service Negotiation . . . . . . . . . . . . . . . . . 6
3.2.3. Dynamic LMA . . . . . . . . . . . . . . . . . . . . . 7
3.2.4. DNS Update . . . . . . . . . . . . . . . . . . . . . . 8
3.2.5. Home Link Emulation . . . . . . . . . . . . . . . . . 9
4. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . . . 9
4.1. PMIPv6 MN-HoA configuration mode . . . . . . . . . . . . . 9
4.2. Use of existing RADIUS Attributes . . . . . . . . . . . . 10
4.2.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . 10
4.2.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . 11
4.2.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . 11
4.2.4. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . 11
4.2.5. Service-Type . . . . . . . . . . . . . . . . . . . . . 11
4.2.6. Framed-Protocol . . . . . . . . . . . . . . . . . . . 11
4.2.7. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key . . . . . 11
5. Diameter Considerations . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative references . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Xia & Sarikaya Expires January 2, 2008 [Page 3]
Internet-Draft RADIUS-PMIP6 July 2007
1. Introduction
It is possible to support mobility for IPv6 nodes by extending Mobile
IPv6 [RFC3775] signaling and reusing the home agent via a proxy
mobility agent in the network. [I-D.ietf-netlmm-proxymip6] describes
the approach to supporting mobility without requiring the mobile node
to be involved in mobility management signaling. The proxy mobility
agent in the network performs the signaling and does the mobility
management on behalf of the mobile node. From AAA perspective, the
operation of Proxy Mobile IPv6 includes the following parts:
Access Authentication. When MN attaches to an access link connected
to the MAG, the MN presents its identity, MN-Identifier, as part
of the access authentication procedure. Upon a successful access
authentication, MAG acting as an RADIUS client obtains the MN's
profile from AAA servers through RADIUS protocol. The profile
probably contains the following information: LMAA, FQDN of LMA,
address configuration mode, MN-HoA, Home link Prefix and it's
length , IPv4 LMAA when transport network is IPv4, IPv4 MN-HoA
when MN is IPv4 enabled, and so on.
Security Association Establishment. After a successful access
authentication and authorization, the MAG MUST send a Proxy
Binding Update(PBU) message to the MN's LMA. The signaling
messages, Proxy Binding Update and Proxy Binding Acknowledgement
are protected using IPsec. In PMIP6 scenario, a pair of security
associations between LMA and MAG are shared by multiple MNs.
Before sending Proxy Binding Update message, MAG checks if there
is a SA ready between the MAG and the LMA. MAG initiates SA
establishment procedure if there is no existing SA. IKEv2 is used
to setup security associations between the MAG and the LMA. The
MAG and the LMA can use any of the authentication mechanisms
(shared secret/certificate/EAP), as described in [RFC4877], for
mutual authentication. When EAP is used, the three parties of the
authentication are MAG as a supplicant, LMA as an authenticator,
and RADIUS server as an authentication server. If the
authentication succeeds, the RADIUS server sends a RADIUS Access-
Accept packet containing the EAP-Success and the AAA-Key derived
from the EAP authentication method. The AAA-Key is used for
further SA establishment between MAG and LMA.
MN home address configuration . An important function of PMIPv6 is
emulation of the mobile node's home link on the access link. Home
address configuration is an important characteristics of links.
The MN can be operating in an IPv4-only mode, IPv6-only mode or in
dual IPv4/IPv6 mode. MN can obtain IPv6 address through DHCPv6.
In this case, MAG can relay DHCP message between MN and DHCP
server, or act as a DHCP proxy. In the latter, MAG can obtain IP
Xia & Sarikaya Expires January 2, 2008 [Page 4]
Internet-Draft RADIUS-PMIP6 July 2007
address from AAA server, or from LMA through PBU/PBA exchange. MN
can also use the prefix in RA advertised by MAG to statelessly
configure an IPv6 address. The prefix can be obtained from AAA
server or LMA. Once MN-HoA address configuration is finished, MAG
sends Access-Request for triggering a MN's DNS update by the
RADIUS.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terminology in this document is based on the definitions in
[I-D.ietf-netlmm-proxymip6], in addition to the ones specified in
this section.
Simple IP Service. Access to the Internet without any mobility
protocol.
3. Solution Overview
3.1. MIP6 Bootstrapping Overview
[RFC4640] is problem statement for bootstrapping Mobile IPv6. In
MIP6 scenario, a MN needs at least the following information: a home
address, a home agent address, and a security association with home
agent to register. The process of obtaining this information is
called bootstrapping. [RFC4640] discusses issues involved with how
MN can be bootstrapped and various potential deployment scenarios for
MN's bootstrapping.
Two deployments scenarios are defined in [RFC4640]: split scenario
and integrated one. The essential difference between the two
scenarios is that in split scenario, the mobility service and the
network access service are authorized by different entities while in
integrated scenario, the two services are authorized by the same
entities. [I-D.ietf-mip6-bootstrapping-split] details bootstrapping
solution in split scenario, while
[I-D.ietf-mip6-bootstrapping-integrated-dhc] describes the solution
for integrated one. Furthermore, [I-D.ietf-mip6-hiopt] defines new
DHCP options used for dynamic home information discovery in
integrated scenario.
To facilitate the solutions, the AAA functionality for the integrated
Xia & Sarikaya Expires January 2, 2008 [Page 5]
Internet-Draft RADIUS-PMIP6 July 2007
and the split scenario needs to be defined. [I-D.ietf-mip6-radius]
defines new RADIUS attributes to facilitate Mobile IPv6 bootstrapping
in both integrated and split scenarios.
[I-D.ietf-dime-mip6-integrated] describes Diameter interface between
a network access server and home AAA server in integrated scenario.
[I-D.ietf-dime-mip6-split] specifies Diameter interface between a
home agent and an AAA server in split scenario.
3.2. PMIP6 Bootstrapping Procedure
Proxy Mobile IPv6 offloads mobility management to networks. As a
proxy, MAG at least needs the following information: a home agent
address, a home address or MN-Identifier, a security association with
LMA to register the MN with LMA. The process of obtaining this
information will be called PMIPv6 bootstrapping in this document.
Both split and integrated scenarios in Section 3.1 are applicable to
Proxy Mobile IPv6. However, the integrated scenario seems more
suitable to PMIPv6 because the access authentication is a part of the
bootstrapping. Because of this, we will not present all the details
of PMIPv6 bootstrapping but instead we will only highlight special
considerations that apply.
3.2.1. Security Association Setup
IKEv2 is used to setup security associations between the MAG and the
LMA to protect the Proxy Binding Update and Proxy Binding
Acknowledgment messages. These security associations can be shared
by multiple MNs. The MAG and LMA can use any of the authentication
mechanisms (shared secret/certificate/EAP) described in [RFC4877] for
mutual authentication. When EAP is used, LMA acting as an
authenticator gets AAA-key from RADIUS server through RADIUS Access-
Accept message. The AAA-Key is used for further SA establishment
between MAG and LMA.
3.2.2. Service Negotiation
Based on the quality of the networks, accounting policy, application
distribution and so on, the user can choose one of the following
services: Simple IP access, PMIPv6 with or without IPv4 support,
Hybrid access (such as, for dual stack, IPv4 is used for local access
while IPv6 is supported as PMIPv6), and so on. There are two
alternatives for service choice: static configuration and dynamic
negotiation. In the former, MN's services are statically configured
in it's profile stored in AAA server. In the latter, MN dynamically
negotiates services with AAA server, as elaborated in
[I-D.xia-netlmm-service-negotiation]. Based on the result of service
negotiation or a static profile, the AAA server configures the
Xia & Sarikaya Expires January 2, 2008 [Page 6]
Internet-Draft RADIUS-PMIP6 July 2007
service through RADIUS Framed-Protocol attribute described in
Section 4.2.6. Different service needs different forwarding and
accounting policy. The MAG is the policy enforcement point (PEP).
3.2.3. Dynamic LMA
[I-D.ietf-mip6-hiopt] defines a DHCP-based scheme to enable dynamic
discovery of Mobile IPv6 home agent address, home agent FQDN and home
subnet. Similarly, MAG can act as DHCP client to dynamically request
LMAA, or LMA FQDN.
MN MAG AAA DHCP-S or DHCP-R
| | | |
| Access Authentication | |
|<----------->|<----------------->| |
| | | |
| | Access-Accept | |
| |<------------------| |
| | | |
| | | |
| | DHCP solicit | |
| |----------------------------------->|
| | | |
| | DHCP advertise | |
| |<-----------------------------------|
| | | |
| | DHCP request | |
| |----------------------------------->|
| | | |
| | DHCP reply |
| |<---------------------------------- |
| | | |
Figure 1: Dynamic LMA Using DHCP
As illustrated in Figure 1, LMAA or LMA's FQDN can be included in
RADIUS Access-Accept message. LMAA MUST be used if it is present.
LMA's FQDN can be used to retrieve LMAA from either DHCP server or
DNS server if LMAA is not present in RADIUS Access-Accept message.
If there isn't any LMA's information in Access-Accept, MAG can
dynamically find a LMA from it's local DHCP server.
Xia & Sarikaya Expires January 2, 2008 [Page 7]
Internet-Draft RADIUS-PMIP6 July 2007
3.2.4. DNS Update
In order that the MN is reachable through its dynamically assigned
Home Address, the DNS needs to be updated with the new Home Address.
Since the DNS update must be performed securely in order to prevent
attacks or modifications from malicious nodes, the node performing
this update must share a security association with the DNS server.
In this case the MAG may not share a security association with the
DNS server and the DNS entry update can be performed by the AAA
server. In order to accomplish this, the MAG sends to the AAA server
the FQDN-HoA pair using the RADIUS protocol
LMA MAG AAA DNS server
| | | |
| 1 PBU | | |
|<------------| | |
| | | |
| 2 PBA | | |
|------------>| | |
| | | |
| Address Configuration | |
| | | |
| | 3 Access-Request | |
| |------------------>| |
| | | 4 DNS Update |
| | |<-------------->|
| | | |
| | 5 Access-Accept | |
| |<------------------| |
| | | |
Figure 2: DNS Update through AAA
Figure 2 illustrates a typical MN-HoA DNS Update procedure
1. After successful access authentication and authorization, the MAG
MUST send a Proxy Binding Update message to the LMA. The Proxy
Binding Update message MUST have the Home Network Prefix option.
MAG can learn the prefix from AAA server or from other means, and
include the prefix in the Home Network Prefix option for
requesting it from the local mobility anchor. If the specified
value is 0::/0, then the LMA will allocate a prefix to the mobile
node.
2. Successful PBA includes confirmed prefix which is advertised in
Router Advertisement message by MAG to MN for stateless address
auto-configuration.
Xia & Sarikaya Expires January 2, 2008 [Page 8]
Internet-Draft RADIUS-PMIP6 July 2007
3. Once address configuration finishes, the MAG sends Access-Request
with MIP6-DNS-MO Attribute defined in [I-D.ietf-mip6-radius].
4. The AAA server performs the DNS update based on [RFC2136].
5. MIP6-DNS-MO attribute SHOULD be included in Access-Accept to
confirm DNS update.
3.2.5. Home Link Emulation
In PMIP6, MAG is also responsible for emulating the MN's home link on
the access link. The characteristics of links are prefix, address
configuration mode, MTU, link layer address of the default address
and so on. To keep the consistency of link characteristics, MN's
prefix is allocated from LMA or AAA server. MN's address
configuration mode SHOULD be conveyed in Access-Accept in PMIP6-HL-
Feature attribute defined in Section 4.1 . The other parameters have
limited impact on MN's behavior, so we offer no further discussion.
4. RADIUS Attributes
We define a new attribute and then describe the existing attributes
in [I-D.ietf-mip6-radius] that are reused in PMIPv6.
4.1. PMIPv6 MN-HoA configuration mode
The new defined attribute is included in Access-Accept message for
MAG to emulate MN's home link.
Xia & Sarikaya Expires January 2, 2008 [Page 9]
Internet-Draft RADIUS-PMIP6 July 2007
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 | Length |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| DHCP server address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
to be defined by IANA.
Length:
The length of the attribute.
M bit:
1-bit "Managed address configuration" flag. When set, MN uses
stateful protocol (that is, DHCP) for address auto-configuration,
and DHCP server's address is included in the attribute. When M
bit is not set, MN uses stateless address configuration.
Reserved:
Reserved for future use.
DHCP server address:
When M bit is set, the field holds DHCP server's address.
4.2. Use of existing RADIUS Attributes
[I-D.ietf-mip6-radius] defines the following new RADIUS attributes
for MIPv6 bootstrapping. In this document, these attributes are
properly reused in PMIPv6 scenario.
4.2.1. MIP6-HA Attribute
The RADIUS server may dynamically assign a LMA to the MN based on LMA
location and current load.
Xia & Sarikaya Expires January 2, 2008 [Page 10]
Internet-Draft RADIUS-PMIP6 July 2007
4.2.2. MIP6-HA-FQDN Attribute
The RADIUS server may assign an FQDN of the LMA to the MN. MAG can
perform DNS query or DHCP request with the FQDN to derive the LMA
address.
4.2.3. MIP6-HL-Prefix Attribute
The RADIUS server may assign a Home Link that is in close proximity
to the MAG. The MN can use the prefix to formulate MN-HoA.
4.2.4. MIP6-DNS-MO Attribute
By using this payload the MAG as a RADIUS client instructs the RADIUS
server to perform a dynamic DNS update.
The following attributes defined in [RFC2865] are extended.
4.2.5. Service-Type
Service-Type (6) SHALL set its value to "Framed" (2).
4.2.6. Framed-Protocol
It MAY be used in both Access-Request and Access-Accept packets. The
values of the attribute are extended as following: IPv4 (7), IPv6
(8), IPv6/IPv4 dual stack (9), PMIPv6 IPv4 support (10), PMIPv6 IPv6
support (11).
4.2.7. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key
To transport the MSK from the RADIUS server to LMA, RADIUS SHALL
utilize the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in
[RFC2548] .
5. Diameter Considerations
When used in Diameter, the attributes defined in this specification
can be used as Diameter AVPs from the Code space 1-255 (RADIUS
attribute compatibility space). No additional Diameter Code values
need be therefore allocated.
6. Security Considerations
The MAG and the LMA to the RADIUS server transactions must be
adequately secured. Otherwise there is a possibility that fraudulent
Xia & Sarikaya Expires January 2, 2008 [Page 11]
Internet-Draft RADIUS-PMIP6 July 2007
values are received from a rogue RADIUS server. The new attributes
defined in this document do not introduce additional security
considerations.
7. IANA consideration
The type of attribute PMIPv6 MN-HoA configuration mode MUST be
assigned by IANA. The value of the attribute Framed-Protocol MUST
also be assigned by IANA.
8. Acknowledgements
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
9.2. Informative references
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for
bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
September 2006.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-01 (work in progress),
June 2007.
Xia & Sarikaya Expires January 2, 2008 [Page 12]
Internet-Draft RADIUS-PMIP6 July 2007
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-00
(work in progress), April 2007.
[I-D.ietf-mip6-bootstrapping-split]
Giaretta, G., "Mobile IPv6 bootstrapping in split
scenario", draft-ietf-mip6-bootstrapping-split-05 (work in
progress), May 2007.
[I-D.ietf-mip6-bootstrapping-integrated-dhc]
Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-04 (work in
progress), June 2007.
[I-D.ietf-dime-mip6-split]
Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA
Support", draft-ietf-dime-mip6-split-02 (work in
progress), May 2007.
[I-D.ietf-dime-mip6-integrated]
Korhonen, J., "Diameter Mobile IPv6: Support for Network
Access Server to Diameter Server Interaction",
draft-ietf-dime-mip6-integrated-04 (work in progress),
May 2007.
[I-D.ietf-mip6-hiopt]
Jang, H., "DHCP Option for Home Information Discovery in
MIPv6", draft-ietf-mip6-hiopt-05 (work in progress),
June 2007.
[I-D.ietf-mip6-radius]
Chowdhury, K., "RADIUS Mobile IPv6 Support",
draft-ietf-mip6-radius-02 (work in progress), March 2007.
[I-D.xia-netlmm-service-negotiation]
Xia, F. and B. Sarikaya, "PMIPv6 service negotiation based
on EAP", draft-xia-netlmm-service-negotiation-00 (work in
progress), May 2007.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
Xia & Sarikaya Expires January 2, 2008 [Page 13]
Internet-Draft RADIUS-PMIP6 July 2007
Authors' Addresses
Frank Xia
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Xia & Sarikaya Expires January 2, 2008 [Page 14]
Internet-Draft RADIUS-PMIP6 July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Xia & Sarikaya Expires January 2, 2008 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 05:31:54 |