Internet Engineering Task Force T. Nishitani
Internet-Draft S. Miyakawa
Expires: January 3, 2009 NTT Communications
July 2, 2008
Carrier Grade Network Address Translator (NAT) Behavioral Requirements
for Unicast UDP, TCP and ICMP
draft-nishitani-cgn-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 3, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines basic terminology for describing different
types of carrier-grade Network Address Translation (NAT) behavior
when handling Unicast UDP, TCP and ICMP. Developing carrier-grade
NATs that meet this set of requirements increase transparency of data
between carrier networks.
Nishitani & Miyakawa Expires January 3, 2009 [Page 1]
Internet-Draft Carrier Grade NAT July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The policy of assignment of CGN external IP address, port
and identifier . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Unicast UDP Requirements . . . . . . . . . . . . . . . . . . . 8
5. TCP Requirements . . . . . . . . . . . . . . . . . . . . . . . 9
6. ICMP Requirements . . . . . . . . . . . . . . . . . . . . . . 9
7. Summary of Requirements . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative Reference . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Nishitani & Miyakawa Expires January 3, 2009 [Page 2]
Internet-Draft Carrier Grade NAT July 2008
1. Introduction
Global IPv4 address from the IANA pool will run out in a few years,
thus carriers need to shift from IPv4 services to IPv6 ones.
However, IPv6 deployment seems to take a long time.
NAT [RFC3022] is a key technology to utilize IPv4 global address
effectively in current practice. ISP may have to place NAT devices
between end-users and the public Internet to suppress global IPv4
address consumption.
In this document, we call carrier's NAT device Carrier Grade NAT
(CGN). This document describes behavioral requirements of CGN for
unicast UDP, TCP and ICMP. [RFC4787], [I-D.ietf-behave-tcp] and
[I-D.ietf-behave-nat-icmp] describes requirements of unicast UDP, TCP
and ICMP for NAT which is placed on network edge and is intended for
high transparency of NAT. CGNs also need interoperability and high
transparency among carriers to make end-users be able to use various
services like Peer-to-Peer(P2P) applications and Instant Messenger.
[RFC5128] is nominated for an NAT traversal condition in P2P.
The main target of this document is 4-4-4 model which uses IPv4
address both internal and external side of CGN.
[I-D.durand-v6ops-natv4v6v4] describes 4-6-4 model, and CGN may apply
to 4-6-4 model.
Interaction of this requirements and security of Customer Premises
Equipment(CPE) is out of scope because CPE should defend itself.
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].
Readers are expected to be familiar with [RFC4787] and the terms
defined there. The following term are used in this document:
Carrier-grade NAT(CGN): NAT devices placed between CPE and public
Internet by a carrier. CGN converts CPE IP Address, CPE Port, and
CPE Identifier into CGN external IP Address, CGN external Port and
CGN external Identifier in communication between CPE and GGN
external.
CGN external realm: The realm where IPv4 global addresses are
assigned
Nishitani & Miyakawa Expires January 3, 2009 [Page 3]
Internet-Draft Carrier Grade NAT July 2008
CGN internal realm: The realm placed between CGN and CPEs
CGN external IP address: The IP address on CGN in CGN external
realm corresponding to CPE IP address
CGN external port: The port on CGN in CGE external realm
corresponding to CPE port
CGN external identifier: The identifier of ICMP on CGN in CGN
external realm corresponding to CPE identifier
Customer Premises Equipment(CPE): The terminal which is placed in
CGN internal realm and may establish TCP sessions to CGN external
realm
CPE IP address: The IP address on CPE in CGN internal realm
CPE port: The port on CPE in CGN internal realm
CPE identifier: CPE's identifier of ICMP in CGN internal realm
CPE 3-tuple: The tuple of TCP/UDP, CPE IP address, and CPE Port
Carrier Service Server (CSS) The server a carrier supplies various
services for CPE
Carrier Service Server (CSS): The server a carrier supplies
various services for CPE
++------++
| CSS |
++------++
|
|
|
CGN external IP address Y1 |
CGN external port y1 |
++------++ CGN external realm
........... | CGN |...............
++------++ CGN internal realm
|
CPE IP address X1 |
CPE port x1 |
++------++
| CPE |
++------++
Nishitani & Miyakawa Expires January 3, 2009 [Page 4]
Internet-Draft Carrier Grade NAT July 2008
CGN network
3. The policy of assignment of CGN external IP address, port and
identifier
A CGN has a pool of CGN external IP addresses, ports and identifiers.
CPEs share CGN external IP addresses. Each CGN occupies combination
of CGN external IP address and CGN external port exclusively. For a
fair use of limited resources, CGN has a limitation for the number of
the CGN external ports per CPE. CGNs need to keep high transparency
to continue existing services after a carrier introduces CGN.
Requirement of high transparency for CGN leads to high scalability of
CGN. High transparency means CGN basically keeps communications
among CPEs except effect of limitations of the number of CGN external
ports and TCP sessions.
A CPE MAY apply UDP hole punching or TCP hole punching for
interactive services among CPEs like Voice over IP and P2P. CGN
SHOLUD NOT interfere in services using UDP hole punching or TCP hole
punching.
REQ-1: A CGN MUST allocate one external IP address to each CPE.
a) CGN external IP address of the UDP, TCP and ICMP MUST be same.
Justification: If a CGN allocates multiple CGN external IP addresses
to each CPE, some applications might not work.
REQ-2: A CGN MUST allocate CGN external ports corresponding to CPE
ports of UDP.
a) A CGN MUST NOT overload CGN external port while a NAT UDP
mapping timer does not expire.
b) A CGN MAY overload CGN external port after a NAT UDP mapping
timer expires.
c) A CGN SHOULD limit the number of the CGN external ports of UDP
per CPE.
d) The number of the CGN external ports of UDP per CPE which CGN
can allocate SHOULD be configurable for the administrator of CGN.
e) A CGN SHOULD NOT allocate well-known ports as CGN external
ports.
Justification: CPEs can communicate to CPE external realm fairly by
Nishitani & Miyakawa Expires January 3, 2009 [Page 5]
Internet-Draft Carrier Grade NAT July 2008
limiting the number of CGN external ports per CPE.
REQ-3: A CGN MUST allocate CGN external ports corresponding to CPE
ports of TCP.
a) A CGN MUST NOT overload CGN external port while the port is
allocated for one or more TCP sessions originated by another CPE.
b) A CGN MAY reuse CGN external port while the port is allocated
for no session originated by any CPE.
c) A CGN SHOULD limit the number of the CGN external ports of TCP
per CPE.
d) The number of the CGN external ports of TCP per CPE SHOULD be
an administratively configurable option.
e) A CGN SHOULD limit the number of the new sessions of TCP per
time unit and per CPE.
f) A CGN SHOULD NOT allocate well-known ports as CGN external
ports.
Justification: CPEs can communicate to CPE external realm fairly by
limiting the number of CGN external ports per CPE. In addition, TCP
CGN external port MAY have TCP sessions, and therefore the TCP
session timer is necessary for every 5-Tuple. CGN can have not only
the limitations of the number of CGN external ports but also TCP
sessions per CPE. Thus a CGN can prevent denial of service attacks
with the tons of TCP open and close by malicious CPEs.
REQ-4: A CGN MUST allocate CGN external identifiers corresponding to
CPE identifiers.
a) A CGN MUST NOT overload CGN external identifier before an ICMP
Query session timer expires.
b) A CGN MAY overload CGN external identifier after an ICMP Query
session timer expires.
c) A CGN SHOULD limit the number of the CGN external identifier
allocated per CPE.
d) The number of the CGN external identifiers per CPE which CGN
can allocate SHOULD be an administratively configurable option.
Justification: CPEs can communicate to CPE external realm fairly by
limiting the number of CGN external identifiers every CPE.
Nishitani & Miyakawa Expires January 3, 2009 [Page 6]
Internet-Draft Carrier Grade NAT July 2008
When a CGN limits the number of CGN external ports and TCP sessions,
CPE may not use TCP services during using web and P2P services. For
example, some services using Ajax demand few dozens of TCP sessions.
P2P software like BitTorrent demands also TCP sessions more than few
dozens. Some CPEs MAY use E-mail services like POP3 and SMTP even
though CPE uses the services which demand many TCP sessions at the
same time. Therefore it is important to reserve CGN external ports
for such administratively configured services.
REQ-5: Reserving CGN external ports per CPE for the always-available
services are RECOMENDED.
a) The destination port which is used for reservation of CGN
external ports SHOULD be administratively configurable.
Justification: To reserve the CGN external ports for specific
services, CPE can avoid the effect of the limitation of CGN external
ports by CGN.
In addition, it MAY not be necessary to set a limit to the number of
CGN external ports for the communications between CPEs and CSS. The
reason is because CGN should pass-through the communications between
CPEs and CSS.
X1:x1 X1':x1' X2:x2
+---+from X1:x1 +---+fromX1:x1 +---+
| |to X2:x2 | | to X2:x2 | |
| C |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| C |
| P | | G | | S |
| E |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| S |
| |from X2:x2 | |fromX2:x2 | |
+---+ to X1:x1 +---+ to X1:x1 +---+
pass-through
REQ-6: A CGN SHOULD pass-through the communication between CPEs and
CSS.
Justification: Using pass-through, CGN does not have to assign CGN
external IP address, ports, and identifiers and limit to the number
of ports and TCP sessions for the services that a carrier manages.
Nishitani & Miyakawa Expires January 3, 2009 [Page 7]
Internet-Draft Carrier Grade NAT July 2008
4. Unicast UDP Requirements
[RFC4787] describes requirements of the Unicast UDP of a NAT, and the
behavior of "Endpoint-Independent Filtering "is RECOMMNEDED, and a
NAT MUST have an "Endpoint-Independent Mapping" behavior to ensure
transparency of CGN.
To have "Endpoint-Independent Filtering" and "Endpoint-Independent
Mapping" behaviors for CGNs, CGNs help to establish UDP Hole Punching
among CPEs. In other words, the possibility of the establishment of
UDP Hole Punching among CPEs which have CGN is equal to the
possibility among CPEs which don's t have CGN. If CGNs have an
"Address-Dependent Mapping" or "Address and Port-Dependent Mapping"
behavior, the possibility that establishment of UDP Hole Punching is
less than when CGNs have an "Endpoint-Independent Mapping" behavior.
And if CGNs have an "Address and Port-Dependent Filtering" behavior,
the possibility that establishment of UDP Hole Punching is less than
when CGNs have an "Endpoint-Independent Filtering" or "Address
Dependent Filtering" behavior. Because a CSS is placed external CGN
realm, the source IP address and port of the communication from CPE
to CSS is CGN external IP address and port. It is RECOMMENDED to use
STUN[I-D.ietf-behave-rfc3489bis] if CPEs check the CGN external IP
address and port for CPE.
A carrier MAY introduce TURN [I-D.ietf-behave-turn] to support
communications among CPEs. If CGN supports "Hairpinning", CGN can
hairpin the communications between CPEs in the same CGN. Therefore
the requirements of Hairpinning for CGN MAY reduce requirements for
the performance of TURN servers. When CPEs decide the course of UDP
between CPEs, CPE MAY use [I-D.ietf-mmusic-ice] .
X1:x1
+------+ from X1:x1 to X2':x2'
| CPE1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>++----++X1':x1'
+------+ | C |
| G |
| N |
X2:x2 | |
+------+ from X1':x1' to X2:x2 | |
| CPE2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<++----++X2':x2'
+------+
Haripinning
REQ-7: A CGN SHOULD comply with [RFC4787] for unicast UDP.
Nishitani & Miyakawa Expires January 3, 2009 [Page 8]
Internet-Draft Carrier Grade NAT July 2008
Justification: CGN SHOULD have to keep high transparency for unicast
UDP communications. And CPE MAY use P2P and interactive services
between CPEs after a carrier introduces CGN.
5. TCP Requirements
[I-D.ietf-behave-tcp] describes requirements of TCP of a NAT, and the
behavior of "Endpoint-Independent Filtering" is RECOMMNEDED, and a
NAT MUST have an "Endpoint-Independent Mapping" behavior to ensure
transparency of CGN
To have "Endpoint-Independent Filtering" and "Endpoint-Independent
Mapping" behaviors for CGNs, CGNs help to establish TCP Hole Punching
among CPEs. In other words, the possibility of the establishment of
TCP Hole Punching among CPEs which have CGN is equal to the
possibility among CPEs which don's t have CGN. If CGNs have an
"Address-Dependent Mapping" or "Address and Port-Dependent Mapping"
behavior, the possibility that establishment of TCP Hole Punching is
less than when CGNs have an "Endpoint-Independent Mapping" behavior.
And if CGNs have an "Address and Port-Dependent Filtering" behavior,
the possibility that establishment of TCP Hole Punching is less than
when CGNs have an "Endpoint-Independent Filtering" or "Address
Dependent Filtering" behavior. Because a CSS is placed external CGN
realm, the source of IP address and port of the communication from
CPE to CSS is CGN external IP address and port. It is RECOMMENDED to
use STUN[I-D.ietf-behave-rfc3489bis] if CPEs want to check the CGN
external IP address and port for CPE.
A carrier MAY introduce TURN [I-D.ietf-behave-turn] to support
communications among CPEs. If CGN supports "Hairpinning", CGN can
hairpin the communications between CPEs in the same CGN. Therefore
the requirements of Hairpinning for CGN MAY reduce requirements for
the performance of TURN servers. When CPEs decide the course of TCP
between CPEs, CPE MAY use [I-D.ietf-mmusic-ice] .
REQ-8: A CGN SHOULD comply with [I-D.ietf-behave-tcp] for TCP.
Justification: CGN SHOULD have to keep high transparency for TCP
communications. And CPE MAY use P2P and interactive services between
CPEs after a carrier introduces CGN.
6. ICMP Requirements
[I-D.ietf-behave-nat-icmp] describes requirements of ICMP of a NAT.
And there MAY be a case that CPE cannot establish communication from
CPEs to CGN external realm because CGN limits the number of CGN
Nishitani & Miyakawa Expires January 3, 2009 [Page 9]
Internet-Draft Carrier Grade NAT July 2008
external ports, identifiers and TCP sessions per CPE. It is useful
if CPE can distinguish an error to occur by the limitation of the CGN
external ports, identifiers and TCP sessions from other errors.
REQ-9: A CGN SHOULD comply with [I-D.ietf-behave-nat-icmp] for ICMP.
a) When a CGN can't establish new session of TCP/UDP by limiting
of TCP/UDP ports per user, the CGN sends an ICMP destination
unreachable message, with code of 13 (Communication
administratively prohibited) to the sender.
Justification: CGN SHOULD have to keep high transparency for ICMP.
And CPE MAY use P2P and interactive services between CPEs after a
carrier introduces CGN. And it is necessary to be able to
distinguish an error to occur by the limitation of the CGN external
ports and TCP sessions from a network error.
7. Summary of Requirements
REQ-1: A CGN MUST allocate one external IP address to each CPE.
a) CGN external IP address of the UDP, TCP and ICMP MUST be same.
REQ-2: A CGN MUST allocate CGN external ports corresponding to CPE
ports of UDP.
a) A CGN MUST NOT overload CGN external port while a NAT UDP
mapping timer does not expire.
b) A CGN MAY overload CGN external port after a NAT UDP mapping
timer expires.
c) A CGN SHOULD limit the number of the CGN external ports of UDP
per CPE.
d) The number of the CGN external ports of UDP per CPE which CGN
can allocate SHOULD be configurable for the administrator of CGN.
e) A CGN SHOULD NOT allocate well-known ports as CGN external
ports.
REQ-3: A CGN MUST allocate CGN external ports corresponding to CPE
ports of TCP.
a) A CGN MUST NOT overload CGN external port while the port is
allocated for one or more TCP sessions originated by another CPE.
Nishitani & Miyakawa Expires January 3, 2009 [Page 10]
Internet-Draft Carrier Grade NAT July 2008
b) A CGN MAY reuse CGN external port while the port is allocated
for no session originated by any CPE.
c) A CGN SHOULD limit the number of the CGN external ports of TCP
per CPE.
d) The number of the CGN external ports of TCP per CPE SHOULD be
an administratively configurable option.
e) A CGN SHOULD limit the number of the new sessions of TCP per
time unit and per CPE.
f) A CGN SHOULD NOT allocate well-known ports as CGN external
ports.
REQ-4: A CGN MUST allocate CGN external identifiers corresponding to
CPE identifiers.
a) A CGN MUST NOT overload CGN external identifier before an ICMP
Query session timer expires.
b) A CGN MAY overload CGN external identifier after an ICMP Query
session timer expires.
c) A CGN SHOULD limit the number of the CGN external identifier
allocated per CPE.
d) The number of the CGN external identifiers per CPE which CGN
can allocate SHOULD be an administratively configurable option.
REQ-5: Reserving CGN external ports per CPE for the always-available
services are RECOMENDED.
a) The destination port which is used for reservation of CGN
external ports SHOULD be administratively configurable.
REQ-6: A CGN SHOULD pass-through the communication between CPEs and
CSS.
REQ-7: A CGN SHOULD comply with [RFC4787] for unicast UDP.
REQ-8: A CGN SHOULD comply with [I-D.ietf-behave-tcp] for TCP.
REQ-9: A CGN SHOULD comply with [I-D.ietf-behave-nat-icmp] for ICMP.
a) When a CGN can't establish new session of TCP/UDP by limiting
of TCP/UDP ports per user, the CGN sends an ICMP destination
unreachable message, with code of 13 (Communication
Nishitani & Miyakawa Expires January 3, 2009 [Page 11]
Internet-Draft Carrier Grade NAT July 2008
administratively prohibited) to the sender.
8. IANA Considerations
There are no IANA considerations.
9. Security Considerations
If malicious CPE can camouflage CPE 3-Tuple, the malicious CPE MAY
prevent a normal CPE from sending data to external realm. Therefore,
a carrier SHOULD make p olicies to prevent a spoofing of CPE 3-tuple.
10. Acknowledgements
Thanks for the input and review by Yasuhiro Shirasaki, Takeshi
Tomochika, Kousuke Shishikura, Dai Kuwabara, Tomoya Yoshida, Takanori
Mizuguchi.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, March 2008.
[I-D.ietf-behave-tcp]
Guha, S., "NAT Behavioral Requirements for TCP",
draft-ietf-behave-tcp-07 (work in progress), April 2007.
[I-D.ietf-behave-nat-icmp]
Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP protocol",
Nishitani & Miyakawa Expires January 3, 2009 [Page 12]
Internet-Draft Carrier Grade NAT July 2008
draft-ietf-behave-nat-icmp-08 (work in progress),
June 2008.
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-15 (work in progress),
February 2008.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-08 (work in progress), June 2008.
11.2. Informative Reference
[I-D.shirasaki-isp-shared-addr]
Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida,
"ISP Shared Address after IPv4 Address Exhaustion",
draft-shirasaki-isp-shared-addr-00 (work in progress),
June 2008.
[I-D.durand-v6ops-natv4v6v4]
Durand, A., "Distributed NAT for broadband deployments
post IPv4 exhaustion", draft-durand-v6ops-natv4v6v4-01
(work in progress), February 2008.
Authors' Addresses
Tomohiro Nishitani
NTT Communications Corporation
Tokyo Opera City Tower 21F, 3-20-2 Nishi-Shinjuku, Shinjuku-ku
Tokyo 163-1421
Japan
Phone: +81 3 6800 3214
Email: tomohiro.nishitani@ntt.com
Nishitani & Miyakawa Expires January 3, 2009 [Page 13]
Internet-Draft Carrier Grade NAT July 2008
Shin Miyakawa
NTT Communications Corporation
Tokyo Opera City Tower 21F, 3-20-2 Nishi-Shinjuku, Shinjuku-ku
Tokyo 163-1421
Japan
Phone: +81 3 6800 3262
Email: miyakawa@nttv6.jp
Nishitani & Miyakawa Expires January 3, 2009 [Page 14]
Internet-Draft Carrier Grade NAT July 2008
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Nishitani & Miyakawa Expires January 3, 2009 [Page 15]