One document matched: draft-wakikawa-manet-ipv6-support-02.txt
Differences from draft-wakikawa-manet-ipv6-support-01.txt
MANET Working Group Ryuji Wakikawa
INTERNET DRAFT Keio University/WIDE
Expires:07 Sep 2006 Antti Tuimonen
Helsinki University of Technology
Thomas Clausen
LIX, Ecole Polytechnique
07 Mar 2006
IPv6 Support on Mobile Ad-hoc Network
draft-wakikawa-manet-ipv6-support-02.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 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 1]
Internet Draft IPv6 MANET 07 Mar 2006
Abstract
This draft defines the IPv6 addressing architecture for Mobile Ad-hoc
Network. This document includes problem statements when manet using
IPv6, IPv6 addressing model, IPv6 manet node's required addresses.
Note that this document does not discuss how an IPv6 address is
allocated to each manet node.
Contents
Status of This Memo 1
Copyright Notice 1
Abstract 1
1. Introduction 2
2. IPv6 Addressing for MANET 2
2.1. Link Local Unicast Address . . . . . . . . . . . . . . . 2
2.2. Unique Local Unicast Address . . . . . . . . . . . . . . 3
2.3. Global Unicast Address . . . . . . . . . . . . . . . . . 4
3. Manet node requirements 4
3.1. General node's required Address . . . . . . . . . . . . . 4
3.2. Optional required address for global communication . . . 5
4. Source Address Selection 5
5. Neighbor Discovery Protocol for MANET 5
5.1. Neighbor Cache Resolution . . . . . . . . . . . . . . . . 6
5.2. Address Auto-configuration . . . . . . . . . . . . . . . 6
5.3. Duplicate Address Detection . . . . . . . . . . . . . . . 6
6. MANET Routing Protocols 7
6.1. Message Flooding . . . . . . . . . . . . . . . . . . . . 7
6.2. Neighbor Sensing . . . . . . . . . . . . . . . . . . . . 8
6.3. Consideration of Longer IPv6 Address . . . . . . . . . . 8
7. Running Mobility Protocols 8
7.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Network Mobility . . . . . . . . . . . . . . . . . . . . 9
References 10
Authors' Addresses 12
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 1]
Internet Draft IPv6 MANET 07 Mar 2006
1. Introduction
This document investigates issues when IPv6 [3] is operated with
mobile ad hoc networks. In general, routing protocols disregard
differences between IPv4 and IPv6, and suggest both can be supported
if routing messages for both protocols are defined. However, there
are some differences which may well affect how the routing protocols
should work with IPv6.
In addition there are several issues that may or may not be covered
in other documents. This document tries to provide information about
implementing and deploying IPv6 mobile ad hoc networks. Addressing
in mobile ad hoc networks is a problem for both IPv4 and IPv6. When
manet connects to the global Internet, IPv4 might do NAT, but in IPv6
we want to have a more integrated solution. This means potentially
acquiring an address with global scope. In an effort to alleviate
problems related to address scopes [2], we first study applicability
of each scope of addresses to mobile ad hoc networks and give
guidelines for IPv6 address assignment. After defining address
assignment, we briefly discuss the Neighbor Discovery Protocol [10]
operations and manet operations on IPv6 mobile ad hoc networks.
2. IPv6 Addressing for MANET
IPv6 has a notion of ``scope'' to control validity of each IPv6
address. In a manet, a link-local scope is used to identify a
physical link and an edge of a manet is identified by a unique-local
scope. A global scope is used for global communication to the
Internet.
2.1. Link Local Unicast Address
A link local unicast address is designed to use with on-link
neighbors, but not over multi-hop. The IPv6 specification prohibits
forwarding packets sent to/from a link local address over a link.
A manet does not have a clear link definition in terms of multi-hop
routing. Indeed, there are two interpretations of ``on-link'' in
manet observation.
- physical medium [9]
The link local address is valid only with one-hop neighbors.
- manet wide (till an edge of a manet)
The link local address is valid over multi-hop. However it
breaks the original definition of link local address.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 2]
Internet Draft IPv6 MANET 07 Mar 2006
Considering fact that many IPv6 related protocol including the
Neighbor Discovery Protocol have already been operated with the
legacy link local address definition, it is reasonable to inherit
the original interpretation of ``link'' for manets. Otherwise, it
could break interoperability between a manet node and a node on the
Internet. It is possible that a node visits both an IPv6 network and
a manet.
The link local address is used only for communication with
1-hop neighbors. This address is also used for the Neighbor
Discovery Protocol. The link-local all-manet-node multicast
address (ff02::TBD) is used for application flooding described in
Section 6.1.
Routes for link local addresses MUST NOT be exchanged over multi-hop
neighbors by manet routing protocols. A node may exchange routes
for link local address with 1-hop neighbors, but this should be done
carefully. This is because whenever a manet node moves and a set of
1-hop neighbors is changed, the route becomes invalid. Thus, each
manet node must carefully maintain routes for link local address.
2.2. Unique Local Unicast Address
A unique local unicast address is not routable on the global
Internet, however it can be used for local communication within
limited area such as site and manet. More characteristics
are described in [7]. A unique local unicast address is not
automatically generated, but it is assigned through address
auto-configuration [12], DHCPv6 [6], static, etc in an IPv6 network.
The locally assigned unique local prefix is generated randomly
by each network and assigned it without any verification of its
uniqueness. Even when a unique local prefix is duplicated, the
damage of this duplication is kept in minimum, because the duplicated
prefix is valid within each limited area and is not used for global
communication. Unless two networks are merged, they cannot know of
duplication of the unique local prefix.
IPv6 enabled mobile ad-hoc networks can be treated as a limited area
due to its different routing approaches from the Internet (IGP, BGP,
etc). A unique Local Unicast address is expected to be assigned to
all manet nodes. The unique local unicast address is used only for
local communication within manets.
Routes for unique local address should be advertised and exchanged
within a manet. These routes MUST NOT be leaked out to the Internet.
Even if some routes for unique local addresses are leaked out, the
backbone routers located to the Internet would often reject and
ignored these routes. It is easier to exclude routes for unique
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 3]
Internet Draft IPv6 MANET 07 Mar 2006
local addresses from the global Internet in terms of different
address scope.
2.3. Global Unicast Address
A global unicast address is routable on the global Internet and
used for communications on the Internet. A global unicast address
must be unique on the Internet. Having a global unicast address
is not mandated to all manet nodes, but only to manet nodes which
need global Internet connectivity. The notion of global unicast
address is applied without any changes to manets. Only manet nodes
which want global connectivity acquires a global unicast address
through some mechanism. A global unicast address can be used for
both local communication within a manet and global communication to
the Internet.
Routes for topologically correct global address can be advertised
to the Internet. However, these routes MUST be aggregated.
Un-aggregated routes, like host routes often used within a
manet, SHOULD NOT be re-distributed to outside the manet without
aggregation.
On the other hand, some manet nodes may have a home address of
Mobile IPv6 [8] and a mobile network prefix of the NEMO basic
support protocol [4]. The routes for a home address and a mobile
network prefix SHOULD NOT be leaked to the Internet because of
topologically incorrectness. Otherwise, it will disrupt the IPv6
routing architecture. Detailed operations can be found in Section 7
3. Manet node requirements
This section describes required address(es) for each manet
node. There are two classification, General required address and
extra-required address for Connected manet ( [11])
3.1. General node's required Address
An isolated manet is a network formed dynamically with wireless manet
nodes, but which is disconnected from the global Internet. This is
defined in [11].
Each manet node MUST generate a link local address according to the
IPv6 specification [3] and MUST also obtain a unique local address.
A unique local prefix, used for the generation of the unique local
address, is identical to all nodes within each mobile ad-hoc network.
The unique local address is generated from locally assigned unique
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 4]
Internet Draft IPv6 MANET 07 Mar 2006
global ID [7]. How to auto-configure an unique local address is out
of scope for this specification.
Even if two manets are merged, or if a manet is partitioned, the
nodes should keep the originally assigned unique local prefix.
When two manets are merged, they can exchange routes of two unique
local prefixes within the merged manet, and can communicate between
different unique local prefixes. This can avoid address conflicts
and prevents storm of duplicate address detection when manets are
merged. When a manet is partitioned, two networks now share the
same unique local prefix. However, these prefixes are not routed in
the global Internet. Thus, this is not problematic unless the two
manets re-merge. Each manet may re-assign a new unique local prefix
for merged/separated scenarios. However, this completely depends on
address configuration mechanism and its operation.
3.2. Optional required address for global communication
A connected mobile ad-hoc network is a wireless multi-hop network
that has global connectivity to the Internet by using Internet
Gateway [13] or OSPF extensions.
Each manet node acquires a global unicast address for global
communication. The assignment of global unicast address is needed
for connected mobile ad-hoc network. Whenever a manet node detects
that the global address is not topologically correct in a foreign
network, it MUST release the invalid global address and obtain
topologically correct address.
Note that manet routes for global addresses should not be leaked to
the Internet without aggregation.
4. Source Address Selection
RFC3484 [5] specifies the source/destination address selection
algorithm. There is no special treatment for manets and each manet
node uses the proposed default algorithm defined in [5].
5. Neighbor Discovery Protocol for MANET
Neighbor Discovery Protocol (NDP) assumes to be run on a link.
However a manet does not have clear definition of ``link'' as
described in Section 2. A manet is wireless multi-hop network and
all manet nodes inside a manet is expected to be a router. Thus,
this section discuss how NDP can be made fit for manets.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 5]
Internet Draft IPv6 MANET 07 Mar 2006
Similar to the current NDP protocol, the IPv6 Hop Limit field of
both Router Solicitation (RS), Router Advertisement (RA), Neighbor
Solicitation (NS), Neighbor Advertisement (NA), and Redirect message
must be set to '255' all the time. The IP Hop Limit field set to 255
indicates, that the packet should not be forwarded by a router.
5.1. Neighbor Cache Resolution
Although a manet does not have the clear definition of link, a manet
node can resolve a neighbor cache (i.e. MAC address) of one-hop
neighbors by using NS and NA messages sent to and from link-local
addressed. It is enough for manet nodes to resolve neighbor caches
of one-hop neighbors, because manet nodes do not share the physical
link with two-hop neighbors.
Even if a manet node can resolve a neighbor cache of two-hop
neighbors, it can not send packets directly to the two-hop neighbors
due to lack of L2 routing mechanisms. Each manet node manages
neighbor caches for one-hop neighbors and confirms manet node's
reachability for one-hop neighbors by using NS and NA (i.e. NDP).
Neighbor nodes, located more than one-hop away, are confirmed by the
manet routing protocol governing the network.
It is important to inherit original interpretation of link for NDP. A
manet node is not always connected to a manet, but it can be attached
to an IPv6 link. In such case, a manet node does not need to change
the operation of NDP, while there is no mechanism to detect whether
attached network is a manet or a normal IPv6 network.
5.2. Address Auto-configuration
IPv6 has an address auto-configuration scheme based on exchange of RS
and RA. However, the address auto-configuration is not designed for
wireless multi-hop networks (i.e. manets). A manet needs to extend
or re-invent address auto-configuration schemes for global addresses
and unique local addresses. For global addresses, it is required
that the addresses must be topologically correct and routable.
[13].
5.3. Duplicate Address Detection
Duplicate Address Detection (DAD) can guarantee the uniqueness of any
scope of addresses by sending a NS for a target address. If a NA
is detected in response to the NS, the address is duplicated. DAD
only defends addresses on a physical link due to link-local scope
limitation of NS and NA. Thus, DAD can be conducted to guarantee
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 6]
Internet Draft IPv6 MANET 07 Mar 2006
only the uniqueness of addresses within one-hop neighbors. (Note
that even if there is no duplication within on-hop neighbors, it
is possible that two-hop neighbors may have a duplicated address.)
This is not useful because one-hop neighbors are often changed due
to node mobility. Once neighbors are changed, the uniqueness is not
guaranteed. Each manet node SHOULD stop using DAD and use another
duplication address detection mechanism specially tuned for manet.
6. MANET Routing Protocols
6.1. Message Flooding
There are two different forwarding engines for message flooding for
manet routing protocols such as ``application forwarding'' and ``IP
forwarding''.
- Application Forwarding:
For application forwarding, it is required that each application
(ex. routing daemon) must send a flooded packet with single
hop-limit to all neighbors. The recipient processes the
flooded packet and will re-send it to all its neighbors if
necessary. The flooded packets are thus repeatedly forwarded
by an application until it has reached all nodes inside mobile
ad-hoc network. Most of manet routing protocol use application
flooding for protocol message exchanges.
- IP Forwarding
Flooded packets can be forwarded by IP layer. The forwarding is
totally blind from applications. If a destination is multicast
address, an application on each manet node receive the flooded
packet, but the flooded packet is forwarded to next neighbors at
IP layer at the same time. The application should not need to
re-send the flooded packet.
For application flooding, each manet node sends a flooded packet to
the link-local all-manet-node multicast address (ff02::TBD). If the
flooded packet is used to setup a route for the sender node (i.e.
reverse route), it should use the address except for link-local
address as a source address. This is because routes for link local
addresses are garbage on multihop networks. Otherwise, the source
address should be set to a link-local address due to one hoplimit
packets.
For IP forwarding, each manet node needs to send a flooded
packet from either global address or unique local address to an
all-manet-multicast address that is currently undefined. The
all-manet-multicast address can be defined for global scope, but must
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 7]
Internet Draft IPv6 MANET 07 Mar 2006
be defined for unique local scope, too. This is because all manet
nodes do not always have global address.
6.2. Neighbor Sensing
Most manet routing protocols uses hello message to sense 1-hop
neighbors. IPv6 permits allocating multiple addresses to a single
interface. For example, a manet node may have 3 addresses (such as
a link-local address, a unique local address, and a global address).
In that case, each manet node SHOULD contain addresses except for
link local addresses (i.e. the unique local and global address).
Even if the link local address is included in hello messages, the
route for the link local address SHOULD not be maintained on each
manet node. The link local address SHOULD be used to send NS and NA
for Neighbor Cache resolution.
6.3. Consideration of Longer IPv6 Address
The length of IPv6 address is 128-bit which is 4 times longer than
IPv4 address. Therefore, protocol messages including IPv6 routes are
tend to be longer than the IPv4 counterparts. Specially in proactive
routing protocols, as a number of manet nodes are increased, routing
messages could be longer. If routing messages becomes larger than
the link MTU, the messages are fragmented by IP layer. This should
be avoided since one piece of fragmented packets can be dropped due
to unstable manet path (depending on topology change speed). Each
manet node SHOULD avoid IP fragmentation of each routing messages by
divided the routing messages into multiple messages at higher than IP
layer (i.e., applications). In alternative way, routing messages can
be shorten by any header or data compression mechanisms.
7. Running Mobility Protocols
7.1. Mobile IPv6
In Mobile IPv6 [8], a mobile host has a permanent global scope
address called its ``home address''. When a mobile host roams into a
manet, it can still use the home address as a source or destination
address of communications.
Although a mobile host can exchange routes for its home address
(global scope) within manet by using the appropriate manet routing
protocol, these routes should not be leaked to the Internet (i.e.
IGP) as described in Section 2.3. This is because a home address is
not topologically correct global address and leaking topologically
incorrect routes disturbs the IPv6 routing architecture.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 8]
Internet Draft IPv6 MANET 07 Mar 2006
When a manet is an isolated manet, a mobile host can not acquire a
global address and can not form a care-of address so that it will
give up sending a binding update to its home agent. Although Mobile
IPv6 does not explicitly prohibit using unique-local address as a
care-of address, but there is no specification for that. A mobile
host can keep using its home address in a visiting manet by exchange
a manet route of its home address. In such case, the mobile host
does not use a bi-directional tunnel between it and home agent, but
it sends packets along to manet routes.
On the other hand, when a manet is connected manet, a mobile host
can acquire a global address and register the care-of address to
its home agent. The mobile host can communicate with either a home
address and a care-of address in a manet by route exchanges. When
the mobile host communicates with a destination located in the same
manet, it may have a host route toward the destination and can skip
using bi-directional tunnel for the destination. If a destination
is outside manet, the mobile host must encapsulate packets to its
home agent as Mobile IPv6 does [8]. The mobile host may use route
optimization for a destination located in either manet or the
Internet.
7.2. Network Mobility
In the NEMO Basic Support protocol (NEMO) [4], a mobile router has
a permanent global scope prefix called ``mobile network prefix''.
A mobile router may also roam into manet with its mobile network
prefix.
A mobile router can exchange a route of its home address (global
scope) and its mobile network prefix within manet by using manet
routing protocols. However these routes should not be leaked to
the Internet (i.e. IGP) as described in Sectionglobal, too. It
is because a home address and a mobile network prefix are not
topologically correct global address at the visiting manet and
leaking topologically incorrect routes disturbs the IPv6 routing
architecture.
When a mobile router, which is NEMO mobile router but not manet node,
roams into an isolated manet, it can not acquire a care-of address
and will give up home registration to its home agent. However,
the mobile router can exchange manet route for its mobile network
prefix and use the manet route for communications from/to its mobile
network. The mobile router should not try to use a bi-directional
tunnel as NEMO does.
On the other hand, when a manet is connected manet, a mobile router
can acquire a global address and register the care-of address to its
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 9]
Internet Draft IPv6 MANET 07 Mar 2006
home agent. The mobile router also exchange manet route for its
mobile network prefix. When the mobile route finds that a manet
route of a destination is in its routing table (i.e. destination
is located within the same manet), it can bypass all procedure of
NEMO (i.e. tunneling to home agent, etc) and will forward packets
along the manet route. If not, the mobile router process packets and
tunnel them to its home agent according to binding information. NEMO
does not specify any route optimization scheme.
Note that some issues related NEMO might be solved by using
manet [1].
Acknowledgments
The authors would like to thank all the participants of OLSR
workshop@San Diego.
References
[1] T. Clausen, E. Baccelli, and R. Wakikawa. NEMO
Route Optimisation Problem Statement (expired,
draft-clausen-nemo-ro-problem-statement-00.txt). Internet
Draft, Internet Engineering Task Force, October 2004.
[2] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, and B. Zill.
IPv6 Scoped Address Architecture. Request for Comments
(Standards Track) 4007, Internet Engineering Task Force, March
2005.
[3] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6)
Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998.
[4] V. Devaraplli, R. Wakikawa, A. Petrescu, and P. Thubert.
Network Mobility (NEMO) Basic Support Protocol (proposed
standard). Request for Comments 3963, Internet Engineering Task
Force, January 2005.
[5] R. Draves. Default Address Selection for Internet Protocol
(IPv6). Request for Comments (Standards Track) 3484, Internet
Engineering Task Force, February 2003.
[6] R. Droms, J. Bound, B. Volz, and T. Lemon. Dynamic Host
Configuration Protocol for IPv6 (DHCPv6). Request for Comments
(Best Current Practice) 3315, Internet Engineering Task Force,
July 2003.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 10]
Internet Draft IPv6 MANET 07 Mar 2006
[7] R. Hinden and B. Haberman. IPv6 Scoped Address Architecture.
Request for Comments (Standards Track) 4193, Internet
Engineering Task Force, October 2005.
[8] D. Johnson, C. Perkins, and J. Arkko. Mobility support in
IPv6. Request for Comments (Proposed Standard) 3775, Internet
Engineering Task Force, June 2004.
[9] J. Manner and M. Kojo. Mobility related terminology. Request
for Comments 3753, Internet Engineering Task Force, June 2003.
[10] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (ipv6). Request for Comments (Draft Standard)
2461, Internet Engineering Task Force, December 1998.
[11] S. Ruffino, P. Stupar, and T. Clausen. Autoconfiguration in a
MANET: connectivity scenarios and technical issues. Internet
Draft (draft-ruffino-manet-autoconf-scenarios-00) , Internet
Engineering Task Force, October 2004.
[12] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard) 2462,
Internet Engineering Task Force, December 1998.
[13] R. Wakikawa, J. Malinen, C. Perkins, A. Nilsson, and
A. Tuominen. Global Connectivity for IPv6 Mobile Ad Hoc
Networks (work in progress, draft-wakikawa-manet-globalv6-05).
Internet Draft, Internet Engineering Task Force, March 2005.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 11]
Internet Draft IPv6 MANET 07 Mar 2006
Authors' Addresses
Ryuji Wakikawa
Keio University
Dept. of Environmental Information
5322 Endo Fujisawa Kanagawa
252, JAPAN
Phone: +81-466 49-1394
EMail: ryuji@sfc.wide.ad.jp
Antti J. Tuominen
Helsinki University of Technology
Laboratory for Theoretical Computer Science
P.O. Box 9201
HUT FIN-02015, Finland
Phone: +358 9 451 5136
Fax: +358 9 451 5351
EMail: anttit@tcs.hut.fi
Thomas Heide Clausen
Project PCRI
Pole Commun de Recherche en Informatique du plateau de Saclay
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud
Ecole polytechnique
Laboratoire d'informatique
91128 Palaiseau Cedex, France
Email: T.Clausen@computer.org
Phone: +33 1 69 33 40 73
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 12]
Internet Draft IPv6 MANET 07 Mar 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 11:26:42 |