Internet DRAFT - draft-shima-nemo-v4prefix
draft-shima-nemo-v4prefix
Network Working Group K. Shima
Internet-Draft IIJ
Expires: April 24, 2006 October 21, 2005
IPv4 Mobile Host/Network support for NEMO Basic Support Protocol
draft-shima-nemo-v4prefix-01
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 April 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo describes the IPv4 Mobile Network Prefix Option which
carries IPv4 network prefix information behind a NEMO router. This
option makes it possible to support IPv4 mobile networks over the
IPv6 network infrastructure.
Shima Expires April 24, 2006 [Page 1]
Internet-Draft v4prefix option October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Sample scenarios . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. A train company . . . . . . . . . . . . . . . . . . . . . 4
2.2. Site multihoming . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of the approach . . . . . . . . . . . . . . . . . . . 8
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Option format . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. IPv4 Mobile Network Prefix Option . . . . . . . . . . . . 10
5.2. IPv4 Mobile Network Prefix Registration Status Option . . 11
6. Mobile Router operation . . . . . . . . . . . . . . . . . . . 13
7. Mobile Host operation . . . . . . . . . . . . . . . . . . . . 15
8. Home Agent operation . . . . . . . . . . . . . . . . . . . . . 16
9. Choosing a home agent . . . . . . . . . . . . . . . . . . . . 17
10. Relationship with v4traversal . . . . . . . . . . . . . . . . 18
11. Relationship with NAT . . . . . . . . . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
14. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14.1. An unnumbered tunnel for IPv4 . . . . . . . . . . . . . . 22
15. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Shima Expires April 24, 2006 [Page 2]
Internet-Draft v4prefix option October 2005
1. Introduction
NEMO (RFC3963) [1] specifies the mechanism to provide mobility
functions to IPv6 networks. All IPv6 networks behind a NEMO capable
router can move around all over the Internet with the NEMO router,
without breaking existing connections between nodes inside the moving
network and nodes of the Internet.
The NEMO specification mentions only IPv6 networks. In this
document, we propose an extension which adds the IPv4 network support
to the NEMO specification. With the option we introduce in this
document, we can operate IPv4 mobile networks over the IPv6 network
infrastructure.
Considering the situation that we need to live with both IPv4 and
IPv6 networks during the transition period before we have completely
shifted to IPv6, many IPv4 devices/networks will be used for a long
time. NEMO provides a simple mechanism to enable IPv6 networks move
around the Internet. The technology is expected to be used for
various scenes, such as implementing car/train networks, a personal
area networks, or even providing redundancy to networks of an entire
site of an
organization(draft-nagami-mip6-nemo-multihome-fixed-network [2]).
Supporting only IPv6 devices and dropping IPv4 devices are not good
idea especially in the forthcoming long transition period.
However defining a new mobile network protocol for IPv4 is not
expected, since IPv4 is going to disappear finally. This document
defines a mechanism to provide IPv4 mobile network using IPv6
connections. We can use with both protocols with this proposed
technology and we also can move to IPv6 only network seamlessly when
the IPv4 network completes its role.
Shima Expires April 24, 2006 [Page 3]
Internet-Draft v4prefix option October 2005
2. Sample scenarios
2.1. A train company
Assuming that a train company wants to provide IP connectivity to
their passengers. Considering the current Internet situation, they
cannot ignore IPv4 networks, but at the same time, they need to
support IPv6 for the future. In such a case, the company need to
assign both IPv4 and IPv6 networks in each train. The network can be
designed as Figure 1.
+------------------------------+
| Company network (dual stack) | +---------------+
| +----+ IPv4 Internet |
| +------------+ | +---------------+
| | Home Agent | |
| +------------+ |
+--------------+---------------+
|
|
+--------------------+--------------------+
| IPv6 Internet |
+---+----------------+-----------------+--+
/ | \
Train1 / Train2| \ Train3
+-----+--+ +---+----+ +--+-----+
| Mobile | | Mobile | | Mobile |
| Router | | Router | | Router |
+-+----+-+ +-+----+-+ +-+----+-+
| | | | | |
+-+-+ | +-+-+ | +-+-+ |
|NAT| | |NAT| | |NAT| |
+-+-+ | +-+-+ | +-+-+ |
| | | | | |
----+----+---- ----+----+---- ----+----+----
2001:2DB:1000:1::/64 2001:2DB:1000:2::/64 2001:2DB:1000:3::/64
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
Figure 1: A sample network for a train company
Each train has one IPv6 network and one IPv4 private network for the
Internet service to the passengers. Each mobile router in a train
works as an IPv6 NEMO router as specified in the NEMO specification.
At the same time, each train has a NAT box to translate the internal
private addresses to a global address. A mobile router also register
the global address using the mechanism described in this document. A
home agent located in the train company will create IPv6 tunnel to
every mobile routers and forwards all IPv6 traffic from/to the mobile
Shima Expires April 24, 2006 [Page 4]
Internet-Draft v4prefix option October 2005
routers and also forwards all IPv4 traffic from/to each global
address assigned to each train network using the tunnel connections,
which tunnels are created by the basic NEMO mechanism.
In the above example, a separate NAT box is located to each train,
however, the function can be integrated to each mobile router
depending on the implementation.
2.2. Site multihoming
There is a proposal to provide a site multihoming mechanism using the
NEMO technology ([2]). Considering the current Internet situation,
we cannot ignore IPv4 connectivity when providing an Internet
connection to customers. In this case, the following network design
can be applied.
Shima Expires April 24, 2006 [Page 5]
Internet-Draft v4prefix option October 2005
+---------------------------------+
| Mobile Network Service Provider |
| | +---------------+
| +--+ IPv4 Internet |
| +------------+ | +---------------+
| | Home Agent | |
| +------------+ |
+------------+--------------------+
|
|
+-------+-------+
| IPv6 Internet |
ISP/Internet +-+-----+-----+-+
--------------- | | | --------------------------------
Company | | |
+---+-----+-----+---+ 2001:2DB:1::/48
| Mobile Router | 202.210.1.0/28
+--+--------+-----+-+ 202.200.1.0/28
| | |
| | |
----------+--+- | ---+---+------- 202.200.1.0/28
202.210.1.0/28 | | | 2001:2DB:1:1000::/64
2001:2DB:1:2000::/64 | | |
+-+-+ | +---+---+
|NAT| | |servers|+
+-+-+ | +-------+|
| | +-------+
| |
+========+=====+===============+
| Company internal network |
| 192.168.0.0/24 |
| 2001:2DB:1:3000::/52 |
+==============================+
Figure 2: A sample network for a multihomed site
In the above example, a company network has three network prefixes
for its site. 2001:2DB:1::/48 for IPv6 and 202.210.1.0/28 and
202.200.1.0/28 for IPv4 networks. The internal network, which
usually used for the intranet is NATed. The mobile router placed at
the boundary between the Internet and the company network will
register those three network prefixes using existing NEMO signaling
messages for the IPv6 prefix and the extension described in this
document for IPv4 prefixes.
All IPv4 traffic which source or destination address is in the range
of 202.210.1.0/28 or 202.200.1.0/28 is tunneled between the mobile
router and the home agent located in a Mobile Network Service
Shima Expires April 24, 2006 [Page 6]
Internet-Draft v4prefix option October 2005
Provider using an IPv6 tunnel, which tunnel is created by the basic
NEMO mechanism.
The example also implies that the mobile router located at the
boundary of the company network has multiple IPv6 connectivities to
increase redundancy. If we use the multiple care-of addresses
registration mechanism as described in [2] and [3], we can also
provide a simple NEMO based multihome network, with both IPv6 and
IPv4 support.
Shima Expires April 24, 2006 [Page 7]
Internet-Draft v4prefix option October 2005
3. Overview of the approach
It is one way to define a new protocol which supports IPv4 network
mobility functions. However, assuming that the Internet shifts from
IPv4 to IPv6, it is not a good idea to invent a new protocol for the
old IP protocol. We take the following approaches.
o Do not define any IPv4 extension protocol, since we will not have
IPv4 in the future.
o Do not break existing NEMO specification.
The basic mechanism of the NEMO specification is a simple signal
processing to maintain the location of mobile routers and exchange of
moving network information. All traffic from/to the moving networks
are tunneled between the mobile router and its home agent. The
mechanism is independent of the protocol version transmitted in the
tunnel.
It is possible to use the tunnel to transmit IPv4 packets, to the
condition that we can exchange the IPv4 routing information of the
moving network. For example, using a dynamic routing protocol
between a home agent and a mobile router makes it possible.
We define a new option which provides the way to exchange such
information in NEMO signaling messages. Such an option is useful
when we are using the explicit mode operation to provide network
mobility, since otherwise we cannot know the prefix information
behind a mobile router.
Shima Expires April 24, 2006 [Page 8]
Internet-Draft v4prefix option October 2005
4. Terminology
o mobile node
An IPv6 host or router which has a Mobile IPv6 or a NEMO
function respectively.
o mobile host
An IPv6 host which has a Mobile IPv6 function.
o mobile router
An IPv6 router which has a NEMO function. A mobile router is
usually able to act as a mobile host.
o IPv4 Mobile Network Prefix
An IPv4 network prefix which is assigned to the network
attached to the ingress interface of a mobile router.
o IPv4 Mobile Address
An IPv4 address which identify a mobile host. A mobile router
also can have an IPv4 Mobile Address, if it needs an IPv4
Mobile Address. A mobile router usually has an IPv4 address on
its ingress interface, if it has a IPv4 mobile network. In
that case, the IPv4 Mobile Address is the IPv4 address assigned
to the ingress interface of the mobile router. A mobile router
may need another IPv4 Mobile Address which is not one of the
IPv4 address of the mobile network.
Shima Expires April 24, 2006 [Page 9]
Internet-Draft v4prefix option October 2005
5. Option format
5.1. IPv4 Mobile Network Prefix Option
The IPv4 Mobile Network Prefix Option is carried in a Binding Update
message, indicating the IPv4 network prefix behind a mobile router.
The option may appear multiple times to exchange multiple subnetwork
information operated in a single mobile network.
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 | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Mobile Network Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8 (TBD)
Length
8-bit unsigned integer indicating the length of the option in a
unit of a octet. The field is always set to 6.
I flag
The I flag indicates the specified address in the IPv4 Mobile
Network Prefix field is used as an IPv4 node identifier.
Reserved
This field is reserved for future use. A sender MUST clear
this field before sending, and a receiver MUST ignore this
field.
Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv4
Mobile Network Prefix. The value must be a valid prefix length
for IPv4 networks. A non-contiguous subnet mask is not
supported.
Shima Expires April 24, 2006 [Page 10]
Internet-Draft v4prefix option October 2005
IPv4 Mobile Network Prefix
4 octets field indicating the IPv4 network prefix of a network
behind a mobile router.
If the value of the Prefix Length field is 32, the IPv4 Mobile
Network Prefix field contains an IPv4 Mobile Address. A home
agent may be required some special processing, if an IPv4
Mobile Address is passed.
5.2. IPv4 Mobile Network Prefix Registration Status Option
The IPv4 Mobile Network Prefix Registration Status Option is carried
in a Binding Acknowledgment message, indicating that the IPv4 Mobile
Network Prefix Option has been recognized.
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 | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
9 (TBD)
Length
8-bit unsigned integer indicating the length of the option in a
unit of a octet. The field is always set to 2.
Reserved
This field is reserved for future use. A sender MUST clear
this field before sending, and a receiver MUST ignore this
field.
Status
8-bit unsigned integer indicating the status of IPv4 mobile
network prefix registration status.
0 Success
140 IPv4 prefix registration not permitted
Shima Expires April 24, 2006 [Page 11]
Internet-Draft v4prefix option October 2005
141 Invalid prefix
142 Not authorized for the prefix
143 IPv4 node identifier registration not permitted
144 Forwarding setup failed
Shima Expires April 24, 2006 [Page 12]
Internet-Draft v4prefix option October 2005
6. Mobile Router operation
A mobile router which has IPv4 networks on its ingress interface can
include the IPv4 Mobile Network Prefix option in a Binding Update
message to its home agent. After receiving a successful
acknowledgment from the home agent, the mobile router adds a route
entry which indicates that all traffic from the IPv4 networks is
forwarded to the tunnel interface created between the mobile router
and its home agent.
A mobile router will receive a Binding Acknowledgment message with
the IPv4 Mobile Prefix Registration Status Option when a home agent
supports this extension. If the Binding Acknowledgment does not
include the option, the IPv4 prefix registration cannot be used.
After successful registration of IPv4 network prefixes, a mobile
router forwards all IPv4 packets which source address is in the range
of the registered IPv4 prefix to its home agent using an IPv6 tunnel
created between the mobile router and its home agent, when those IPv4
packets are received from the ingress interface of the mobile router.
On the other hand, when the mobile router receives IPv4 packets from
the tunnel and the destination address of the internal packet is in
the range of the registered IPv4 prefix, the mobile router forwards
those IPv4 packets to its ingress interface.
Figure 3 shows the packet format.
Shima Expires April 24, 2006 [Page 13]
Internet-Draft v4prefix option October 2005
From a mobile router to a home agent
+--------------+ Source: The care-of address of the mobile router
| IPv6 header | Dest: The home agent address
| |
+--------------+ Source: One of IPv4 address registered to the
| IPv4 header | home agent
| | Dest: An arbitrary IPv4 address in the IPv4
+--------------+ Internet
| IPv4 payload |
+--------------+
From a home agent to a mobile router
+--------------+ Source: The home agent address
| IPv6 header | Dest: The care-of address of the mobile router
| |
+--------------+ Source: An arbitrary IPv4 address in the IPv4
| IPv4 header | Internet
| | Dest: One of IPv4 address registered to the
+--------------+ home agent
| IPv4 payload |
+--------------+
Figure 3: Packet format
Shima Expires April 24, 2006 [Page 14]
Internet-Draft v4prefix option October 2005
7. Mobile Host operation
A mobile host can have a fixed IPv4 address, which never change
during handover. We call the address as an IPv4 Mobile Address. A
mobile host specifies its IPv4 Mobile Address in a Binding Update
message. When specifying an IPv4 Mobile Address, a mobile host need
to set the Prefix Length field to 32 and put the IPv4 Mobile Address
in the IPv4 Mobile Network Prefix field of the IPv4 Mobile Network
Prefix Option.
A mobile host will receive a Binding Acknowledgment message with the
IPv4 Mobile Prefix Registration Status Option when a home agent
supports this extension. If the Binding Acknowledgment does not
include the option, the IPv4 node identifier registration cannot be
used.
After successful registration of an IPv4 Mobile Address, the IPv4
node identifier can be used as a source address of IPv4 packets
generated at the mobile host. Such packets are forwarded to the home
agent of the mobile node using an IPv6 tunnel interface created
between those two nodes. If a mobile host receives IPv4 packets
which destination address is same with the IPv4 node identifier of
the mobile host from the IPv6 tunnel interface, the host accepts the
packets as its own packets.
Shima Expires April 24, 2006 [Page 15]
Internet-Draft v4prefix option October 2005
8. Home Agent operation
A home agent which supports the IPv4 Mobile Network Prefix Option
will add a route entry for the IPv4 network prefix when it receives a
Binding Update message with the option. A Binding Acknowledgment
message sent from the home agent must include the IPv4 Mobile Prefix
Registration Status Option to indicate the processing status of the
received IPv4 Mobile Prefix Option.
When a home agent accept the IPv4 Mobile Network Prefix Option, the
status field of the IPv4 Mobile Network Registration Status Option
must be set to 0 indicating success. Otherwise, the status code must
be filled with an error code as described in section Section 5.2.
After successful registration of IPv4 prefixes, a home agent start
forwarding IPv4 packets which destination address is in the range of
registered IPv4 prefix to the tunnel to the mobile router which
registered the corresponding IPv4 prefix. At the same time, the home
agent also start accepting IPv4 packets sent from the tunnel which
source address is in the range of the registered IPv4 prefix and
start forwarding to the IPv4 internet.
If the Prefix Length field in the incoming IPv4 Mobile Network Prefix
Option is equal to 32, a home agent treats the value in the IPv4
Mobile Network Prefix field as an IPv4 Mobile Address. The address
must be one of addresses of the IPv4 network that the home agent is
attached to. If the validation succeeds, a home agent starts
proxying the IPv4 node identifier included in the option (after
checking there is no other nodes which is using the IPv4 address). A
home agent will intercept all IPv4 packets delivered to the home
network if the destination address of the packets is equal to the
IPv4 Mobile Address. These intercepted packets will be forwarded to
the mobile host using an IPv6 tunnel created between the home agent
and the mobile host. If a home agent receives IPv4 packets which
source address is the IPv4 Mobile Address from the IPv6 tunnel
interface, a home agent will forward the packets to the IPv4
Internet.
Figure 3 shows the packet format.
Shima Expires April 24, 2006 [Page 16]
Internet-Draft v4prefix option October 2005
9. Choosing a home agent
A mobile router need to know which home agent supports the option
discussed in this document. One possible way to do it is to define a
special bit in a Dynamic Home Agent Address Discovery message to
indicate that a home agent supports this option. This mechanism
requires to modify all home agent to understand the bit even if the
home agents does not support the IPv4 prefix option.
Another way is to try to register with the option and see what
happen. If the home agent to which a mobile router sent a
registration message supports the IPv4 Network Prefix Option, it will
reply with the IPv4 Network Prefix Registration Status Option.
Otherwise, the status option will not be included. If the home agent
which the mobile router has tried to register does not support the
option, the mobile router can deregister from the home agent and try
another home agent.
Shima Expires April 24, 2006 [Page 17]
Internet-Draft v4prefix option October 2005
10. Relationship with v4traversal
This document describes the mechanism to support IPv4 networks
located behind a mobile router over the IPv6 network infrastructure.
The signaling messages and a tunnel connection between a mobile
router and a home agent uses IPv6.
The v4traversal mechanism provides the way to use IPv4 as a protocol
for signaling messages and tunnel connections. Using the v4traversal
mechanism will provide IPv6 mobile network over the IPv4 network
infrastructure.
These two mechanisms aims the different goals. The combination of
these mechanisms are also possible and when we use these two
mechanism at the same time, we can operate IPv4 mobile networks over
IPv4 network infrastructure.
Shima Expires April 24, 2006 [Page 18]
Internet-Draft v4prefix option October 2005
11. Relationship with NAT
The mechanism described in this document has nothing to do with the
NAT mechanism. As described in Figure 1, a NAT box can be located as
one of internal nodes of an IPv4 mobile network. We do not need to
distinguish the NAT box from other IPv4 nodes.
Of course, it is possible to design the NAT feature in a mobile
router. Such a design will reduce the number of nodes to be managed
in one mobile network. However, the logical network topology is the
same with the network when we operate the NAT box and the mobile
router in theory. Therefore, there is no need to differentiate the
combined case and the separate case. The decision just depends on
the policy and available implementation.
Shima Expires April 24, 2006 [Page 19]
Internet-Draft v4prefix option October 2005
12. Security Considerations
The options defined in this document do not introduce any new
security vulnerability.
Shima Expires April 24, 2006 [Page 20]
Internet-Draft v4prefix option October 2005
13. Acknowledgements
The author would like to thank Satoshi Uda, Kenichi Nagami, Ryuji
Wakikawa, Thierry Ernst and Romain Kuntz for their input.
Shima Expires April 24, 2006 [Page 21]
Internet-Draft v4prefix option October 2005
14. Appendix
14.1. An unnumbered tunnel for IPv4
Some implementation (for example, *BSD implementation) do not support
an unnumbered tunnel for IPv4 communication. In this case, we need
to assign a valid (or just a dummy) IPv4 address on both tunnel end
points of a mobile router and a home agent side. It is possible to
assign non-routable addresses, such as 169.254/16, since the
addresses assigned on the both end of the tunnel interface between a
mobile router and a home agent never used for real communication in
theory. However, an implementor must take care the address selection
algorithm for IPv4 used in their implementation. For example, *BSD
system choose an IPv4 address of the outgoing interface, if we does
not specify the source address explicitly. This makes invalid (which
means, the packet has non-routable address in its source address)
packet to be sent to the Internet.
Shima Expires April 24, 2006 [Page 22]
Internet-Draft v4prefix option October 2005
15. History
o Revision 01
* Added the IPv4 Mobile Address description to support host
mobility.
* Added an appendix section which mentions the unnumbered tunnel
problem.
o Revision 00
* The initial version published on 26th July 2005.
16. References
[1] Devarapalli, Wakikawa, Petrescu, and Thubert, "Network Mobility
(NEMO) Basic Support Protocol", RFC 3963.
[2] Nagami, Uda, Ogashiwa, Wakikawa, Esaki, and Ohnishi, "Multi-
homing for small scale fixed network Using Mobile IP and NEMO",
draft-nagami-mip6-nemo-multihome-fixed-network-03 (work in
progress).
[3] Wakikawa, Uehara, Ernst, and Nagami, "Multiple Care-of Address
Registration", draft-wakikawa-mobileip-multiplecoa-04 (work in
progress).
Shima Expires April 24, 2006 [Page 23]
Internet-Draft v4prefix option October 2005
Author's Address
Keiichi Shima
Internet Initiative Japan Inc.
Jinbo-cho MItsui Bldg.
1-105 Kanda, Jinbo-cho
Chiyoda-ku, Tokyo 101-0051
Japan
Phone: +81 3 5205 6500
Email: keiichi@iijlab.net
URI: http://www.iij.ad.jp/en/
Shima Expires April 24, 2006 [Page 24]
Internet-Draft v4prefix option October 2005
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 (2005). 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.
Shima Expires April 24, 2006 [Page 25]
