One document matched: draft-wakikawa-manet-globalv6-05.txt
Differences from draft-wakikawa-manet-globalv6-04.txt
Mobile Ad Hoc Networking Working Group Ryuji Wakikawa
INTERNET DRAFT Keio University
07 Mar 2006 Jari T. Malinen
Charles E. Perkins
Nokia Research Center
Anders Nilsson
University of Lund
Antti J. Tuominen
Helsinki University of Technology
Global connectivity for IPv6 Mobile Ad Hoc Networks
draft-wakikawa-manet-globalv6-05.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 i]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
Abstract
This document describes how to provide Internet connectivity with
mobile ad-hoc networks. It describes how to obtain a globally
routable address and internet gateway operation. Once a manet node
obtains a global address from an internet gateway, it may exchange
data with nodes on the Internet. This Internet access method is not
dependent on a particular manet protocol. Further, use of global
connectivity with Mobile IPv6 is specified.
Contents
Status of This Memo i
Copyright Notice i
Abstract ii
1. Introduction 2
2. Terminology 3
3. Overview 5
4. Conceptual Data Structures and Messages 6
4.1. Conceptual Data Structures . . . . . . . . . . . . . . . 6
4.2. Internet Gateway Information . . . . . . . . . . . . . . 7
4.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. IGWSOL-N . . . . . . . . . . . . . . . . . . . . 8
4.3.2. IGWADV-N . . . . . . . . . . . . . . . . . . . . 8
4.3.3. IGWCON-N . . . . . . . . . . . . . . . . . . . . 10
4.3.4. DYMO Modifications . . . . . . . . . . . . . . . 10
4.3.5. OLSRv2 Modifications . . . . . . . . . . . . . . 12
4.4. Changing the ICMPv6 Redirect . . . . . . . . . . . . . . 12
5. Manet Node Operation 14
5.1. Receiving Internet Gateway Advertisement . . . . . . . . 14
5.2. Address Autoconfiguration . . . . . . . . . . . . . . . . 14
5.3. Default Route Setup . . . . . . . . . . . . . . . . . . . 15
5.4. Source Address Selection . . . . . . . . . . . . . . . . 16
5.5. Receiving ICMPv6 Error Messages . . . . . . . . . . . . . 16
5.6. Interaction with Mobility Protocols . . . . . . . . . . . 16
6. Reactive Manet Node Operation 18
6.1. Soliciting Internet Gateway Advertisement (Optional) . . 18
6.2. Route Selection for Reactive Protocols . . . . . . . . . 18
6.3. Use of Routing Header . . . . . . . . . . . . . . . . . . 20
R. Wakikawa et.al. Expires 07 Sep 2006 [Page ii]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
7. Internet Gateway Operation 22
7.1. Joining a Mobile Ad-hoc Routing Domain . . . . . . . . . 22
7.2. Sending Internet Gateway Advertisement . . . . . . . . . 22
7.3. Receiving Internet Gateway Solicitation . . . . . . . . . 23
7.4. Management of Manet Nodes on Internet Gateway . . . . . . 23
7.5. Route Examination . . . . . . . . . . . . . . . . . . . . 24
8. Protocol Constants 26
9. Security Considerations 26
Acknowledgments 26
References 26
Appendices 28
Authors' Addresses 28
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 1]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
1. Introduction
A mobile ad-hoc network (manet) is built dynamically when a set
of manet routers creates routing state for their connectivity
management, typically over a wireless network. Manet routing
protocols aim to maintain a route to a destination despite movement
of intermediate nodes that causes the route path to change. There
are routing protocols standardized at IETF such as DYMO [1],
OLSRv2 [2], AODV [11], OLSR [3], DSR [7], and TBRPF [10].
Global connectivity is often required for manet routers desiring
communication with the fixed Internet. However, routing protocols
for manets only maintain routes locally within the reach of a manet
running the given protocol. This document specifies the method by
which a node in the manet acquires a global address from a gateway,
as well as how this node will communicate over the gateway.
The following assumptions are made for simplicity and definiteness:
- Address Family
This document assumes IPv6 address family support. The manet
routing protocol discussed in this document MUST be capable of
routing for IPv6 addresses.
- Topological assumption
There is at least one internet gateway somewhere in the manet.
- Address assumption
All nodes in the manet must have or acquire a routable address,
perhaps usable as a Mobile IPv6 [8] home address. The routable
address is used for initial configuration when a node boots up
and joins the manet
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 2]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
2. Terminology
manet node
A node located inside a manet
internet node
A node located within the Internet (outside manet)
internet gateway
A router which provides Internet connectivity for nodes
in the manet. This router is located somewhere in a
manet and has a connection to both the Internet and the
manet.
manet local address
A manet node's identity address in manet. The address is
used for ad-hoc routing.
global address
A node's IPv6 address in the Internet, typically
resolvable from a DNS name. The address identifies
the mobile node, and is used for communication to the
Internet
internet route
A route to the Internet (i.e. internet gateway). It can
be treated as a default route or a network route.
manet route
A route to other manet nodes. It is typically host route
in a manet.
internet gateway information
The gateway's IP routing prefix, prefix length, and
lifetime.
internet gateway advertisement
A message to disseminate internet gateway information to
a manet.
IGWADV-M
Extends the manet protocol; a control message is
specified for each particular protocol to advertise
internet gateway information
IGWADV-N
Extends NDP to indicate that the advertisement
contains information about the internet gateway
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 3]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
internet gateway solicitation
A message to solicit an internet gateway advertisement.
IGWSOL-M
Extends the manet protocol; a control message is
specified for each particular protocol to solicit
internet gateway information
IGWSOL-N
Extends NDP to solicit an internet gateway
Advertisement.
internet gateway confirmation
A message to confirm an IPv6 global address of a manet
node. This can be an IGWCON or a signaling of each manet
routing protocol (ex. RREP).
IGWCON-M
Extends the manet protocol; a control message is
specified for each particular protocol for the
internet gateway confirmation.
IGWCON-N
Extends NDP for the internet gateway confirmation.
internet gateways multicast address (IGW_MCAST)
Specifically, ALL_MANET_GW_MULTICAST, the IPv6 global
multicast address for all internet gateways in a manet.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 4]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
3. Overview
The global connectivity for manet is defined for any global address
configured to any manet network interface of a manet node, and it
defines a method for configuring a globally routable address for
such an interface. Once such global address is available, global
mobile-initiated sessions, such as web browsing or DNS queries, can
be used. A topologically correct address in the IP header's source
field is sufficient for packets sent from the manet node in such
sessions.
A manet node discovers an internet gateway by receiving an internet
gateway advertisement. Each internet gateway MAY disseminate
internet gateway advertisement proactively. Periodic advertisements,
however, are not typically used with reactive manet protocols such
as DYMO [1], AODV [11] and DSR[7]. Thus, a manet node can solicit
internet gateway advertisement when it needs a route to the Internet,
and will receive internet gateway advertisements back in response.
This solicitation is optional when an internet gateway periodically
floods a internet gateway advertisement. In this way, the reactive
and proactive route discovery features of each manet routing protocol
are not disturbed.
For these internet gateway solicitation and advertisement, we
introduce modifications to the Neighbor Discovery Protocol (NDP) [9]
and each manet routing protocol. Operators can use the preferred
one to implement global connectivity. The proposed method targets
all manet protocols regardless of whether they are reactive or
proactive. An advertisement from the internet gateway provides
prefix information, and advertisement processing possibly resolves a
route to the gateway, inserted as a route toward the Internet (i.e.
Internet Route). A prefix which is distributed by internet gateways
can be used for configuring a (typically globally) routable IPv6 [5]
address for each manet node.
After accepting an advertisement from the internet gateway, the
manet node configures a global address from the prefix of the
internet gateway and inserts the internet gateway address as an
internet route. Each internet gateway monitors packets received
from the manet, to avoid unnecessarily forwarding the packet to the
Internet when the destination is already present within the manet.
The destination of a packet passing through the internet gateway
is checked on the internet gateway. If the manet is operating
reactively, the internet gateway in this case may also supply an
updated route to the sending node. The sending node then receives
a notification and sends a route request to discover the direct
route to the destination. To do so, each intenet-gateway MAY manage
a roster of IP addresses of all the associated manet nodes. The
management is explained in Section 7.4.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 5]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
4. Conceptual Data Structures and Messages
4.1. Conceptual Data Structures
This specification assumes that all manet nodes support the following
data structures. These structures are similar to the data structures
defined in Neighbor Discovery Protocol (NDP)[9]. These structures
can be implemented in several ways. An example is extending the
structures implemented for NDP.
- Internet Gateway List (IGW List)
A list of available internet gateways to which packets may be
sent. In this list, the internet gateway information described
later must be stored. Each entry also has an associated
invalidation timer value (extracted from internet gateway
Advertisements) used to delete entries that are no longer
advertised. The entries are listed below:
1. internet gateway global address
2. internet gateway lifetime
3. internet gateway manet-local address (optional)
- Internet Gateway Prefix List (Prefix List)
A list of prefixes that are advertised by internet gateways.
This Internet Gateway Prefix List entries are created from
information received as internet gateway advertisements. Each
entry has an associated invalidation timer value (extracted from
the internet gateway advertisement) used to expire prefixes when
they become invalid. The entries are listed below:
1. internet gateway prefix address
2. internet gateway prefix address length
3. internet gateway prefix preferred lifetime
4. the number of advertised internet gateways
- Associated MANET nodes list
Each internet gateway manages an associated manet node list for
all the manet nodes to which it supplies a global connectivity.
The following information must be managed on each internet
gateway.
1. A global address of a manet node
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 6]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
4.2. Internet Gateway Information
A manet node needs a globally routable address in order to be
globally reachable, so that it can receive packets from the Internet.
The manet node needs to learn its topological location and an address
of the internet gateway that provided the node with this access to
the Internet. The node therefore needs to obtain a global prefix
owned and distributed by internet gateways. The information which a
manet node needs to know for internet connectivity is listed below.
An internet gateway advertises these items as its internet gateway
information. This internet gateway information is introduced to keep
compatibility with NDP [9].
- internet gateway global address
The internet gateway's global address, which can be used as a
route to the Internet on manet nodes.
- Internet Gateway Prefix address
The network prefix address which internet gateway is serving.
The prefix MUST be valid address and topologically correct
address on the Internet.
- Internet Gateway Prefix length
Prefix length of the network prefix address of an internet
gateway.
- Internet Gateway Prefix Preferred Lifetime
The addresses generated from the prefix via stateless address
autoconfiguration remain preferred [13]. A value of all one bits
(0xffffffff) represents infinity. See [13]. After expiration of
the lifetime, the manet node MUST delete its autoconfigured IPv6
global address.
- Internet Gateway Lifetime
The lifetime of an internet gateway. After expiration of
the lifetime, a manet node MUST NOT use the internet gateway
as an internet route. It SHOULD get fresh internet gateway
information.
- internet gateway's manet address (option)
A manet address which can be used for internal communication with
an internet gateway.
4.3. Messages
This specification defines three messages such as internet gateway
solicitation, internet gateway advertisement and internet gateway
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 7]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
confirmation. Those messages are implemented in two ways: extension
of NDP and extension of manet routing protocol's messages.
As we explained in [14], NDP messages such as a router solicitation,
a router advertisement and a neighbor advertisement are not
originally designed to route over multi-hop, because NDP [9] is
operated between on-link nodes and routers. NDP assumes to use
link-local scoped addresses as the IPv6 destination and source
address fields for router advertisement and router solicitation
messages. Link-local address is not an appropriate address scope for
multi-hop networks since IPv6 prohibits to forward packets sent to an
address of link-local scope. For doing so, new NDP packets must be
defined.
In this section, we introduce three new NDP messages named IGWSOL-N,
IGWADV-N, IGWCON-N and examples of routing signaling modifications
(IGWSOL-M, IGWADV-M, IGWCON-M).
4.3.1. IGWSOL-N
The IGWSOL-N is same as the Route Solicitation message of NDP except
for the Type value.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
TYPE
TBA.
4.3.2. IGWADV-N
The IGWADV-N is similar to the Route Advertisement message of
NDP. However, the internet gateways MUST NOT forward this message
to internet nodes. The sender MUST include a Prefix Information
option [9] with a globally routable prefix. The prefix information
option is not modified for manet global connectivity. However, L
flag must be unset and the Valid Lifetime field MUST be set to zero
for the IGWADV-N, since on-link determination can not be used for
manet. A Source Manet Address option may be required in order to
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 8]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
store a manet local address of the internet gateway, depending on the
manet protocol.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit |A|O| Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
TYPE
TBA.
Code
zero
Checksum
The ICMP checksum.
Hop Limit
The hop count between an Internet Gateway and a manet
node.
A
1-bit ``Acknowledgment'' flag. It requests Internet
Gateway Confirmation to a manet node
O
1-bit ``Other stateful configuration'' flag. When
set, hosts use the administered (stateful) protocol for
autoconfiguration of other (non-address) information.
Router Lifetime
16-bit unsigned integer. The lifetime associated with the
default router in units of seconds. The maximum value
corresponds to 18.2 hours. A Lifetime of 0 indicates that
the router is not a default router and SHOULD NOT appear
on the internet gateway list. The Router Lifetime applies
only to the router's usefulness as a default router; it
does not apply to information contained in other message
fields or options.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 9]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
4.3.3. IGWCON-N
The IGWCON-N is sent only when an internet gateway requests
acknowledgment (ex. Set A flag in IGWADV-N). This message is used to
manage an associated manet node list on the internet gateway.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
TYPE
TBA
Code
zero
Checksum
The ICMP checksum.
Reserved
zero
Target Address
The global address of the manet node. This target address
will be stored in a associated manet node list of an
internet gateway.
4.3.4. DYMO Modifications
DYMO has already specified a gateway concept in the
specification [1]. The internet gateway lifetime can be
retrieved from the route entry's lifetime for the internet gateway.
We defined a new global connectivity block as shown in below. This
global connectivity block is carried by RREP. We also introduces
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 10]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
a new C flag in the ``Reserved'' field of Routing Element (RE) to
indicate an internet gateway confirmation message. RREP can be
recognized as the Internet Gateway Advertisement message, and RREQ is
as the Internet Gateway Solicitation message. The Internet Gateway
Confirmation message can be RREP with C flag set.
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 | Len | TTL |I|A|S|C|Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. TargetAddress .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| THopCnt |Res| .
+-+-+-+-+-+-+-+-+ .
. .
. Routing Block 1 (RBlock1) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C
The C flag indicates requesting Internet Gateway
Confirmation message. A manet node must include its new
global address in a routing block and unicasts it to the
particular internet gateway.
We also define a new DYMO Internet Gateway Prefix Block (IGWBlock) as
follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|I|Prefix Length|R| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. IGW Prefix (i.e. IGW global address) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. IGW Seqno .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGW Prefix Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I
The I flag indicates Internet Gateway Prefix Block (IGW
block) for RE.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 11]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
Prefix Length
The length of IGW global Prefix
R
1 bit Reserved field
Hop Count
Same as the Hop Count of Routing Block (RBlock)
IGW Prefix
The global address of the internet gateway
IGW Seqno
The sequence number of the internet gateway
IGW Prefix Preferred Lifetime
The preferred lifetime of the IGW Prefix.
4.3.5. OLSRv2 Modifications
For OLSRv2, we define a new message TLV for global connectivity
as illustrated in below. The internet gateway lifetime is also
retrieved from the route entry's lifetime for the internet gateway.
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 |L| Reserved | IGWPrefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. IGW Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. IGW Prefix (IGW global address) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGW Prefix Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4. Changing the ICMPv6 Redirect
For global connectivity, an ICMPv6 Redirect message [9] is used by
the internet gateway to notify a sending node that a destination is
located on this manet and instead should send packets to it using
ordinary manet routing. According to [9], a gateway MUST send an
ICMPv6 Redirect messages from only link-local address. However,
in manet situation, an internet gateway needs to send it from non
link-local address due to multihop routing. Thus, we relax this
limitation in this specification. An internet gateway can send
the redirect message from either a manet local address or a global
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 12]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
address. In the target address field, the internet gateway SHOULD
insert the wildcard IPv6 address (i.e. ::).
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 13]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
5. Manet Node Operation
For internet connectivity, each manet node needs to generate a global
address and configure a route to the Internet.
5.1. Receiving Internet Gateway Advertisement
Two different messages are possible for internet gateway
advertisement: IGWADV-N and IGWADV-M. When a manet node receives
an internet gateway advertisement, it first verifies the message
according to either the NDP specification [9] or each routing
protocol specification. In addition to the verification, the manet
node MUST conduct additional check as follows:
- The source address MUST be non link-local address. If the
message is sent from a link-local address, the message MUST be
silently discarded.
- The message MUST have a correct prefix information option.
Otherwise, the message MUST silently be discarded. Each node
MUST verify following items for the prefix information option.
* The prefix address must be global routable prefix address
* The prefix length must be valid length. (i.e. shorter than
128 and greater than 0).
* Prefix Preferred Lifetime must be greater than zero.
For the NDP based Intenet Gateway advertisement message
(IGWADV-N), the following checks is required.
* The Valid Lifetime MUST be set to zero
* L flag MUST be unset and A flag MUST be set
After successful verifications, the manet node keeps the internet
gateway information into the Internet Gateway List and Internet
Gateway Prefix List as described in Section 4.1.
5.2. Address Autoconfiguration
After an internet gateway advertisement has been received from
the internet gateway(s), a manet node SHOULD generate a global
address by using the internet gateway information. The node SHOULD
use its EUI-64 in order to construct a valid address with the
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 14]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
acquired prefix. The address generation is same as NDP Address
Autoconfiguration [13] except for DAD. DAD operation is out of scope.
5.3. Default Route Setup
The manet node SHOULD set a route toward the Internet in the routing
table. An ``example'' of a routing table is as follows:
Destination/prefix length Next-Hop
-------------------------- -----------------------------
Internet Route *
default (::) ** <internet gateway address-A>
default (::) <internet gateway address-B>
: :
Host Route/128 ***
<internet gateway address> <next-hop address>
How to implement to hold a default route is up to manet routing
protocols, implementations and operating systems. Some operating
system (ex. Linux) are capable to keep multiple default routes and
some (ex. BSD) are not supporting multiple routes for the same
destination. It is possible to extend the BSD to hold multiple
entries for a same destination.
Even if a node does not hold multiple internet gateways in a routing
table, it can still keep these information in the internet gateway
list. Thus it can refer the internet gateway list whenever it loses
reachability to the default route which is set in a routing table.
These routing entries MUST be held until expiration of the prefix
lifetime. The router lifetime of the default route entry and the
global prefix information is the same with the prefix lifetime.
During active lifetime, the receiving node can use the global prefix
and the internet gateway as the default route entry. The default
route does not function as the general default route for reactive
route protocols, because the default route MUST be used with the
mechanism described in Section 7.5 in addition to the general route
lookup mechanism.
During active use of the internet gateway as a route path for
communications, the manet node SHOULD update internet gateway
information by receiving internet gateway advertisements. If
necessary, the manet node can unicast an internet gateway
solicitation to the respective internet gateway, or alternatively it
can broadcast an internet gateway solicitation to all over the manet
again. The former method can allow the manet node to update the
current internet gateway status, while the latter method enables the
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 15]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
manet node to quickly discover all possible internet gateways in the
manet.
5.4. Source Address Selection
Each manet node carefully selects a source address for outgoing
communication. For communication, the manet node MUST NOT use its
link-local address. The following decision MUST be made before
sending packets.
- If a destination is an internet node, it MUST use its global
address. The global address can be home address.
- If a destination is a manet node located within the manet, it
SHOULD use it manet-local address. However the manet node MAY
use its global address.
5.5. Receiving ICMPv6 Error Messages
If a manet node receives an ICMPv6 Destination Unreachable message
after sending data packets along a manet route, the node MUST delete
the manet route from the routing table. On the other hand, if the
manet node uses an internet route, it SHOULD NOT delete the internet
route. But it SHOULD stop sending packets to the destination. The
node, then, MAY re-discover the destination by routing requests if
necessary. Unless the node finds the destination node, it must give
up communicating with the destination for a while.
If the manet node receives an ICMPv6 Redirect message from an
internet gateway, the manet node SHOULD use the host route instead
of the default route. Getting the host route, the manet node uses
its method of learning a manet destination, e.g., by sending a route
requests for the destination.
5.6. Interaction with Mobility Protocols
If a global address is more permanent one on a manet node, it can
be used as a Mobile IPv6 [8] home address, to provide an always-on
reachability from the fixed Internet with a statically known address.
In such a case, reachability can be provided even when the node moves
between manets and different points of the fixed network. A mobile
node should use Mobile IPv6 when it is not on its home link. When
arriving at a visited link in the fixed network, it will receive
router advertisements to detect movement. If it is not at home, it
registers with its home agent using a globally routable address from
the visited network. In manet, Mobile IPv6 uses the internet gateway
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 16]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
advertisement to detect node's movement and to generate a globally
routable address (i.e. Care-of address). The same mechanism can be
applied to the NEMO Basic Support protocol [6].
The mobile node uses the globally routable address acquired from the
internet gateway as its care-of-address when possibly performing a
home registration. If no home registration is needed, the mobile
node is at home in the manet and the prefix of its home address
belongs to its internet gateway. If the mobile node starts Return
Routability procedure for route optimization, HoTI and CoTI are sent
through its internet gateway and HoT and CoT are returned to the
mobile node via the internet gateway. There is no special operation
for Return Routability on manet.
All manet nodes SHOULD support Mobile IPv6 Correspondent Node
(CN) requirements describe in [8], so that they understand the
home address option. Manet nodes using Mobile IPv6 with global
connectivity support whatever Mobile IPv6 functionality they wish
to use. Manet mobile nodes SHOULD NOT use home address options and
CN binding updates when exchanging routing information with other
nodes in the manet. This keeps control packets smaller and does
not require manet nodes to support full CN functionality. A manet
mobile node MAY insert a routing header to an outgoing data packet
for explicit gateway routing in addition to the possible home address
option. If the node is a CN, the possible routing header injected by
Mobile IPv6 is modified by inserting the entry for gateway prior to
the entry for home address, and setting the segments left to two.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 17]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
6. Reactive Manet Node Operation
This section introduces additional operations for manet nodes running
reactive manet routing protocols.
6.1. Soliciting Internet Gateway Advertisement (Optional)
A manet node sends an internet gateway solicitation in order
to prompt an internet gateway(s) to generate internet gateway
advertisements.
The following steps are required for sending the internet gateway
solicitation.
- The source address of the message MUST NOT be a link local
address. The IPv6 address used during any of these operations
could be any routable address, for example a Mobile IPv6 home
address. If no such address is available, the node SHOULD
allocate a temporary global-scope address, generated from
the well-known MANET_INITIAL_PREFIX [12]. This temporary
address (MANET_TEMPORARY_ADDRESS) should be deallocated after
obtaining the globally routable IPv6 address from an internet
gateway.
- The manet node unicasts the router solicitation to an internet
gateway if it has already known the address of the internet
gateway. Otherwise, it floods the message to a new all internet
gateway multicast address (i.e. ALL_MANET_GW_MULTICAST).
- The Hop Limit field in the IPv6 header SHOULD be set to an
appropriate value. This can be the default constant usually
inserted when unicasting packets, or chosen e.g., according to
broadcasting/flooding scheme such as an expanding ring search
technique.
6.2. Route Selection for Reactive Protocols
In reactive manets, a manet node and an internet gateways do not know
the complete topology of the manet which they belong to. They MUST
discover a host route for a destination as soon as they start to
communicate. Therefore, whenever a node needs to send a packet it
uses the following routing algorithm:
- The node looks up its routing table for the destination node.
If it found the discovered route, it sends the packet towards
the destination. The internet route SHOULD NOT be selected as a
route for the destination at this point.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 18]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
- If not, the node MAY request a route for the destination node.
1. If an internet route exists, the node MAY wait for the above
route request.
2. If an internet route does not exist, the manet node obtains a
default route.
3. If the manet node does not get any route, the node sets an
route entry into the routing table with the destination node
pointing towards the internet route. Then the manet node
uses the route to transmit the packet through the internet
route.
- If the manet node gets a route for the destination, it sets a
host route for the destination, and sends packets according to
this route (not the internet route).
The node SHOULD know whether a route request was earlier sent for a
destination whose route lookup found the default route. To prevent
repeated route requests for packets destined to the destination, the
node MUST put a route entry for the destination with the internet
route as a next hop of the destination node . An ``example''
routing table of the node SHOULD be configured for the destination as
shown below. As explained in Section 5.2, how to implement to hold
these routes is up to manet routing protocols, implementations and
operating systems.
Destination/prefix length Next-Hop
-------------------------- -----------------------------
Internet Route
:: (default) <internet gateway address>
Host Route/128
<internet gateway address> <next-hop address>
<Destination address> <internet gateway address>
If the protocol allows, the node SHOULD send at least one request
for a route of such a destination before sending data packets, even
if it has already had a default route in its routing table. If the
routing protocol is using an expanding ring search, care should be
taken so as not to let this affect the delay too much. If the ring
is expanded too far, unnecessary delay is introduced. Simulations
have shown that one route request is optimal in most cases.
If the node gets a route for such a destination, the node assumes the
destination node is located within manet, sets a host route for the
destination, and sends packets normally according to this host route.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 19]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
6.3. Use of Routing Header
A manet node sends data along an internet route when a destination
is an internet node. The node has different way to transmit packets
through an internet gateway.
- Without IPv6 routing extension header
The manet node sends the packet to an IP address of an internet
node and relies upon next hop routing in the other nodes.
- With IPv6 routing extension header
The manet node uses the internet gateway address in the
destination address of the IPv6 header and the real destination
address in the routing header.
When a reactive manet routing protocol is used, each node may know
only partial topology or link. In such case, if a packet meant for
an internet node is sent without a routing header, each intermediate
node will try to discover a manet route due to absence of the routing
entry for the destination address. For example, table driven routing
protocol such as AODV may have this problem. Intermediate nodes of
a manet route only knows information of manet nodes on its routing
table. Intermediate nodes do not know that whether the destination
address is located on the Internet until route discovery for the
destination address is completed. In addition, we can not assume
that all manet nodes inside a manet acquire an internet route. If
an intermediate node who does not have an internet route receives a
packet meant for an internet node, it will not be able to route the
packets. Therefore, if the packet is sent with a routing header, the
destination address of the packet is the internet gateway while it is
routed within the manet. Therefore, the intermediate node can route
the packet to the internet gateway without generating additional
route discovery and even without an internet route.
Assume the destination is located inside the manet but the sender
can not reach the destination via a host route. Such the case can
be occurred when reactive manet routing protocol is used. If the
manet node sends packets to the destination via the internet gateway
without a routing header, an intermediate node who has a host route
for the destination will route packets to it directly, but the sender
node is not aware of this. The sender is never notified that packets
is not passing through the internet gateway. If the sender always
uses a routing header, every packet is explicitly routed through
the internet gateway. If the internet gateway detects that the
destination is located within the manet, the internet gateway can
send an ICMPv6 Redirect error message to the sender. After receiving
the ICMPv6 Redirect messages, the manet node can re-discover a manet
route for the destination.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 20]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
Using a routing header is preferable when there are more than two
internet gateways, because the node then have the ability to decide
which internet gateway is the best, by distance in hops, or by some
other priority. By assign a priority number for each internet
gateway, the route reply message and the manet router advertisement
messages could be extended to support a candidate internet gateway
option in it.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 21]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
7. Internet Gateway Operation
This section describes required operation for internet gateways.
7.1. Joining a Mobile Ad-hoc Routing Domain
An internet gateway joins a mobile ad-hoc network with a manet
interface while it maintains the Internet connectivity with other
interfaces.
The internet gateway requires to listen routing messages in order to
collect routing information. However, it should not involve local
manet routing with its manet interface so that route examination
becomes much easier as described in Section 7.5.
The internet gateway SHOULD NOT become an intermediate node of a
manet route. To achieve this, the internet gateway SHOULD NOT
forward the flooded packets to its neighbors of the manet interface.
For example, in AODV, the internet gateway SHOULD NOT propagate a
RREQ message even if it receives the RREQ from neighbors. In OLSR,
the internet gateway SHOULD NOT generate TC message. It can be done
with the Willingness configuration set to NEVER.
7.2. Sending Internet Gateway Advertisement
An internet gateway sends out an internet gateway advertisement
either periodically or response to an internet gateway solicitation.
The internet gateway allows to send unsolicited internet gateway
advertisements, although sending them periodically would generate
unnecessary packets in the Manet.
When an IGWADV-N is used, it MUST carry a Prefix Information
Option [9, 8]. The internet gateway contains its global prefix in
the prefix information option. The source address of the IGWADV-N
must be a global address of the internet gateway and MUST NOT use its
link-local address.
Although the NDP specification requires to set 255 to a hop limit
field, the Hop Limit field in the IPv6 header SHOULD be set to an
appropriate value in a MANET. The internet gateway can either flood
or unicast the internet gateway advertisement. An internet gateway
SHOULD use optimized flooding mechanism such as the expanding ring
search and multipoint relay flooding.
When the internet gateway uses IGWADV-M, it must follow the
specifications of each manet protocols.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 22]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
7.3. Receiving Internet Gateway Solicitation
When an internet gateway receives an internet gateway solicitation,
it MUST unicast an internet gateway advertisement back to the
originator of the solicitation.
When it receives an IGWSOL-N, the internet gateway must operate
following verifications in addition to the verification specified
in [9].
- If the source address is link local address, it SHOULD drop the
IGWSOL-N.
- If the hop limit field of the IGWSOL-N is equal to zero, the
message MUST silently be discarded.
After successful verification, the internet gateway keeps the
originator's global address in its global manet node lists with
INITIAL_GLOBAL_LIFE_TIME. It also unicasts back a IGWADV-N as
described in Section 7.2.
When a IGWSOL-M is received, the internet gateway must verify the
packet and returns IGWADV-M if necessary.
7.4. Management of Manet Nodes on Internet Gateway
An internet gateway SHOULD manage an associated manet node list
for all the manet nodes which acquire a global address from the
internet gateway. This knowledge is used when internet gateway
determines a route for incoming packets described in section 7.5.
It is recommended that the internet gateway supports this feature
specially when reactive manet protocol is used.
When using proactive manet protocols, an internet gateway can see
entire topology of all the manet nodes. Therefore, the internet
gateway can know whether a node locates inside manet or not, as soon
as it checks its topology map. On the other hand, most of reactive
manet protocols only maintain partial topology of manet nodes. Each
manet node MUST contact to the internet gateway at least once it
establishes an internet route with the internet gateway. During this
operation, the internet gateway records the manet node's addresses
into a routing table and SHOULD mark as a manet node who has global
address. This approach can be applied to most of reactive manet
protocol, but any mechanism can be selected to know all manet nodes
information.
To acquire a global address of each manet node, an internet gateway
confirmation message can be used. After address autoconfiguration
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 23]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
on each manet node, the manet node notifies its global address by
sending the internet gateway confirmation message. The internet
gateway ask a manet node to send a internet gateway confirmation
message by setting a flag in an internet gateway advertisement
message. The internet gateway confirmation message will be unicasted
to an internet gateway which a manet node receives the internet
gateway information.
When there are multiple internet gateways, the associated manet node
list SHOULD be exchanged among internet gateways. This exchange
can be done in several way (ex. running routing protocol between
internet gateways, if internet gateways are connected each other by
wired link)
7.5. Route Examination
When an internet gateway forwards a packet from a manet to the
Internet , it must examine the packet's source address. This
examination prevents leaking unnecessary packets to the Internet.
This examination is based on the following steps.
1. The internet gateway first checks the destination address with
its global prefix. If the prefix of the destination address is
matched with the global prefix, the internet gateway MUST NOT
forward the packet to the Internet. It returns the packet back
to the manet if it has a manet route for the destination. If the
internet gateway does not have a manet route, it just discards
the packet and returns an ICMP Unreachable message to the sender.
2. If the prefix of the destination address is not matched with the
global prefix, the internet gateway carefully examines the route
for the destination.
- If the internet gateway can not be an intermediate node of
manet routes as shown in Section 7.4, goes to Step-3 below.
- If the internet gateway can be an intermediate node and knows
full topology of the manet , it searches its routing table
for a manet route of the destination. If the route is found,
it routes the packet back to the manet. The internet gateway
SHOULD generate an ICMP6 Redirect Message to the source node.
- On the other hand, if the internet gateway can be an
intermediate node and does not have full topology, it
compares the destination address with manet nodes' global
addresses maintained in the associated manet node list. If
there is a manet route, it SHOULD route the packet along the
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 24]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
manet route. The internet gateway SHOULD generate an ICMP6
Redirect Message to the source node.
3. The internet gateway compares the source address with its global
prefix. If the prefix part is not matched, this packet is sent
from non-routable address in this manet. Thus, the packet MUST
NOT be routed to the Internet. If there is no manet route for
the destination, the packet MUST be silently discarded. The
internet gateway SHOULD return an ICMP6 Parameter Problem message
to the source node.
4. Otherwise, it can forward the packet to the Internet.
Note that ICMP error messages are subject to rate limiting in the
same manner as is done for ICMPv6 messages [4].
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 25]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
8. Protocol Constants
Parameter Name Value
---------------------- -----
ALL_MANET_GW_MULTICAST TBD (ff1e::xx/64 global-scope)
9. Security Considerations
This document does not define any method for secure operation
of the protocol. There is no widely accepted model for securing
state-altering protocols in manet. A reason for this is the lack of
scalability in security association setup among manet nodes arriving
from arbitrary domains. Before well accepted SA setup methods exist,
any node can pretend to be an internet gateway and result in other
nodes setting their routing state in a way denying proper operation
of this service.
Acknowledgments
The authors would like to thank Elizabeth Royer for her comments
on streamlining some aspects of the design. The authors thank
Thierry Ernst and Fred Templin for his comments. The authors thank
Thomas Clausen for his many improvements having to do with proactive
routing protocols. The authors also thank Alex Hamidian for his
contributions and improvements to section 7.2.
References
[1] I. Chakeres, E. Belding-Royer, and C. Perkins. Dynamic MANET
On-demand (DYMO) Routing (work in progress). Internet Draft,
Internet Engineering Task Force, October 2005.
[2] T. Clausen. The optimized link-state routing protocol version 2
(work in progress). Internet Draft, Internet Engineering Task
Force, August 2005.
[3] T. Clausen and P. Jacquet. Optimized Link State Routing
Protocol OLSR. Request for Comments (Experimental) 3561,
Internet Engineering Task Force, October 2003.
[4] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet protocol version 6 (ipv6)
specification. Request for Comments (Draft Standard) 2463,
Internet Engineering Task Force, December 1998.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 26]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
[5] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6)
Specification. Request for Comments (Proposed Standard) 1883,
Internet Engineering Task Force, December 1995.
[6] 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.
[7] D. Johnson, D. Maltz, and Y. C. Hu. The Dynamic Source Routing
Protocol for Mobile Ad Hoc Networks (DSR) (work in progress,
draft-ietf-manet-dsr-09.txt). Internet Draft, Internet
Engineering Task Force, April 2003.
[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] 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.
[10] R. Ogier, , F. Templin, and M. Lewis. Topology Dissemination
Based on Reverse-Path Forwarding (TBRPF). Request for Comments
(Experimental) 3684, Internet Engineering Task Force, February
2004.
[11] C. Perkins, E. Belding-Royer, and S. Das. Ad hoc On-Demand
Distance Vector (AODV) Routing. Request for Comments
(Experimental) 3561, Internet Engineering Task Force, July 2003.
[12] C. Perkins, J. Malinen, R. Wakikawa, E. Royer, and Y. Sun.
IP address Autoconfiguration for Ad hoc Networks (expired,
draft-ietf-manet-autoconf-01.txt). Internet Draft, Internet
Engineering Task Force, November 2001.
[13] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard) 2462,
Internet Engineering Task Force, December 1998.
[14] R. Wakikawa, A. Tuimonen, and T. Clausen. Ipv6
support on mobile ad-hoc network (work in progress,
draft-wakikawa-manet-ipv6-00.txt). Internet Draft, Internet
Engineering Task Force, February 2005.
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 27]
Internet Draft Global Connectivity for IPv6 Manets 07 Mar 2006
Authors' Addresses
Ryuji Wakikawa Charles Perkins
Dept. of Communications Systems Lab
Environmental Information Nokia Research Center
Keio University 313 Fairchild Drive
5322 Endo Fujisawa Kanagawa Mountain View, California
252 JAPAN 94043 USA
EMail: ryuji@sfc.wide.ad.jp EMail: charliep@iprg.nokia.com
Phone: +81-466 49-1394 Phone: +1-650 625-2986
Fax: +81 466 49-1395 Fax: +1 650 625-2502
Jari T. Malinen Anders Nilsson
Communications Systems Lab Dept. of Communication Systems
Nokia Research Center Lund Institute of Technology
313 Fairchild Drive Box 118
Mountain View, California SE-221 00 Lund
94043 USA Sweden
EMail: Jari.T.Malinen@nokia.com E: andersn@telecom.lth.se
Phone: +1-650 625-2355 Phone: +46 46-39 72 92
Fax: +1 650 625-2502 Fax: +46 46-14 58 23
Antti J. Tuominen
Theoretical Computer Science Lab
Helsinki University of Technology
P.O.Box 9201
FIN-02015 HUT
Finland
Email: anttit@tcs.hut.fi
Phone: +358 9 451 5136
Fax: +358 9 451 5351
R. Wakikawa et.al. Expires 07 Sep 2006 [Page 28]
Internet Draft Global Connectivity for IPv6 Manets 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 29]
| PAFTECH AB 2003-2026 | 2026-04-23 06:15:45 |