One document matched: draft-jelger-manet-gateway-autoconf-v6-00.txt
LSIIT - ULP C. Jelger
Internet-Draft T. Noel
Expires: February 25, 2004 LSIIT
August 27, 2003
Gateway and address autoconfiguration for IPv6 adhoc networks
draft-jelger-manet-gateway-autoconf-v6-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 February 25, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Adhoc networks are formed by the spontaneous collaboration of
wireless nodes when no networking infrastructure is available. When
communication to the Internet is desired, one or more nodes must act
as gateways for the adhoc network. In this case, global addressing of
adhoc nodes is required. This document specifies a protocol (node
behaviour, information propagation, message format) which allows
nodes in an adhoc network to discover a gateway/prefix pair which is
used in order to build an IPv6 global address and, when necessary, to
maintain a default route towards the Internet.
Jelger & Noel Expires February 25, 2004 [Page 1]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Summary of the protocol operation . . . . . . . . . . . . . 4
3. Format of the GW_INFO message . . . . . . . . . . . . . . . 6
4. Sending GW_INFO messages . . . . . . . . . . . . . . . . . . 8
4.1 Proactive protocols . . . . . . . . . . . . . . . . . . . . 8
4.2 Reactive protocols . . . . . . . . . . . . . . . . . . . . . 8
5. Detailed mode of operation . . . . . . . . . . . . . . . . . 10
5.1 Hop-by-hop propagation of GW_INFO messages . . . . . . . . . 10
5.2 Avoiding confusion after nodes movements . . . . . . . . . . 10
5.3 GW_INFO information freshness notification . . . . . . . . . 11
5.4 Algorithms and node behaviour . . . . . . . . . . . . . . . 11
5.4.1 Initial selection algorithm . . . . . . . . . . . . . . . . 12
5.4.2 Maintaining prefix and route information . . . . . . . . . . 13
6. DNS considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Protocol parameters values . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . 20
Jelger & Noel Expires February 25, 2004 [Page 2]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
1. Introduction
In contrast with current wireless networks, adhoc networks require no
pre-existing infrastructure to exist. Because of the inherent
limited propagation range of radio transmissions, adhoc nodes
collaborate to forward (and route) packets within this spontaneous
multi-hop network. Two families of protocols have been proposed by
the IETF MANET working group to achieve routing in adhoc networks.
Reactive protocols like [1] and [2] build routes "on-demand", i.e.
only when a route to a certain destination is needed. In contrast,
proactive protocols like [3] and [4] maintain an up-to-date view of
the network topology and routing tables entries are updated
accordingly.
One of the challenge of adhoc networking is the autoconfiguration of
global addresses, allowing nodes to be reachable from outside the
adhoc network. To achieve this functionality, one (or possibly more)
node of the adhoc network must provide connectivity to the rest of
the Internet, thus acting as a gateway for the other adhoc nodes.
There has been a few proposals (mainly for IP version 4) for
automatic address allocation in adhoc networks, and there has also
been proposals [5] which present ways of discovering a gateway. This
work differs from previous work as follows. First, we combine both
problems (global address configuration and gateway discovery) as done
in classic wired IPv6 networks : the gateway is therefore responsible
for prefix announcement. Second and in contract with previous work,
our method supports multiple gateways which may announce different
global prefixes. Third, our method includes some mechanisms whose aim
is to avoid the propagation of false information during nodes
movements. And fourth, this work aims to propose a method that is
independent (in terms of message semantics) of the underlying routing
protocol. Our proposed method is particularly suited to proactive
protocols which maintain an up-to-date knowledge of their 1-hop
neighborhood by sending periodical HELLO-like messages. While our
proposed method could also be used with reactive protocols with no
modifications to their operation, both its effectiveness and
correctness are greatly increased if periodical HELLO-like messages
are exchanged between a node and its neighbors. This can be
implemented with very little overhead because nodes using a reactive
routing protocol do not need to maintain a knowledge of their
neighborhood. A node indeed only needs to know what prefix has been
selected by each of its neighbor in order to ensure that it is not
isolated from other nodes sharing the prefix it selected. This
feature can either be added to the reactive protocol as part of its
operation or can be implemented in a parallel stand-alone process
(i.e. a daemon in networking terms).
Jelger & Noel Expires February 25, 2004 [Page 3]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
2. Summary of the protocol operation
Nodes periodically exchange gateway and prefix information with their
1-hop neighbors via packets whose content will further be noted
GW_INFO messages. For proactive protocols, this message can be
carried by HELLO packets which are periodically sent by a node to
maintain its 1-hop neighborhood. This technique is very attractive as
it allows nodes to quickly react to topological changes, for example
when a node loses connectivity to its next hop neighbor towards the
gateway. On the other hand, reactive protocols do not strictly use
such a mechanism to maintain a view of their 1-hop neighborhood. We
therefore propose that, with reactive protocols, a light mechanism
MUST be added to the reactive protocol itself, or that a stand-alone
process (a daemon in networking terms) MUST be run in parallel with
the proactive protocol. The objective is to exchange GW_INFO messages
(as detailed in sections 4 and 5) in order for a node to check the
prefix used by its neighbors when multiple gateways are available :
the aim is to ensure that nodes which share a common prefix always
form a continuous neighborhood.
The GW_INFO message contains a number of fields which allow nodes to
exchange gateway information and which also allow a node to select
which gateway is most appropriate if more than one gateway is
available. Without going into details (they are given in Section 3),
the GW_INFO message contains the global address of the gateway, the
length of the prefix part of the address, a sequence number used to
refrain nodes to accept wrong information (e.g. after node
movements), a 3-bit field used by a node to notify its neighbors
about its perceived "freshness" of the information contained in its
GW_INFO messages, and the distance to the gateway as perceived by the
node sending the GW_INFO message.
GW_INFO messages are sent locally with a hop limit of 1, the
propagation of gateway and prefix information is therefore done in a
hop-by-hop manner. Upon reception of GW_INFO messages, each node
follows an algorithm to select and update both the prefix used to
create a global address and the gateway used to send data to nodes
outside the adhoc network. A node receives GW_INFO messages from all
of its neighbors, and must therefore choose to use the information
sent by one of them. The algorithm used to select the most
appropriate information is detailed in another section. When a given
node A decides to use the GW_INFO messages sent by its neighbor B, B
becomes what we define as the upstream neighbor of A. The term is
used throughout this document to refer to node B when node A is
considered. The information received by a node from its upstream
neighbor is used by this node to build its own GW_INFO messages.
It is also here worth mentioning that, in contrast to the work
Jelger & Noel Expires February 25, 2004 [Page 4]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
proposed in [5] for AODV and in the particular case of reactive
protocols, the GW_INFO information is not used to add a default route
towards the gateway. We indeed believe that the reactive nature of
such protocols avoids the need of keeping a default route which, by
nature, prevents such a protocol from being reactive. Details about
this concern are given in section 4.
The rest of this document is organized as such. The next section
details the format of the GW_INFO message. Section 4 details the
methods that should be used to send GW_INFO messages. It also
describes the method that is used by nodes using a reactive routing
protocol in order to check prefix continuity, i.e. to prevent a node
from being isolated from other nodes using the same prefix. Section 5
gives a detailed view of the use of GW_INFO messages and details the
algorithms used by a node to select and update both its prefix and
gateway.
Jelger & Noel Expires February 25, 2004 [Page 5]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
3. Format of the GW_INFO message
The format of the GW_INFO message used to dissemate the gateway and
prefix information is shown in Figure 1. This message is sent via an
IPv6 hop-by-hop header extension. The GW_INFO MUST be sent in an IPv6
packet with a hop limit of 1. The hop-by-hop header extension is
prefered because it can be used with any routing protocol. However,
if the GW_INFO message is integrated within the control packets of a
routing protocol (e.g. in the HELLO messages of a proactive
protocol), the GW_INFO message can be added to the payload of the
control packets. In that case, the two first fields (Next header and
Hdr Ext Len) MUST be removed.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next header | Hdr Ext Len | Option type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Distance |G|L N K| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Gateway Global Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. GW_INFO message format
Next Header : 8-bit selector. Identifies the header following the
hop-by-hop extension. This field is part of the hop-by-hop extension
header format.
Hdr Ext Len : 8-bit unsigned integer. Gives the length of the
extension. MUST be set to 2. This field is part of the hop-by-hop
extension header format.
Option type : 8-bit unsigned integer. To be attributed. Specifies
that the message is a GW_INFO message.
Opt Data Len : 8-bit unsigned integer. MUST be set to 20.
Prefix Length : 8-bit unsigned integer. Gives the length, in bits, of
the prefix part of the gateway address given in the Gateway Global
Address field. The maximum allowed value is 64 (for a /64 prefix).
Distance : 8-bit unsigned integer. Gives the distance to the gateway,
Jelger & Noel Expires February 25, 2004 [Page 6]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
in hops, as perceived by the node sending the GW_INFO message. The
gateway itself MUST set this field to zero.
G bit : a gateway sending GW_INFO messages MUST set this bit to 1.
This SHOULD be manually configured by the administrator of the
gateway.
L N K (link) 3-bit field : these 3 bits are used by a node to
indicate the quality of its link towards its upstream neighbor. The
detailed use of this field is given in the sections 4 and 5.
Sequence number : 16-bit unsigned integer. An integer value used to
avoid the wrong dissemination of GW_INFO information due to nodes
movements. Details about the use of this field are given in section
5.
Gateway Global Address : 128-bit global address of the gateway.
Jelger & Noel Expires February 25, 2004 [Page 7]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
4. Sending GW_INFO messages
Our proposed protocol strongly relies on the way by which GW_INFO
messages are exchanged. A node indeed needs to quickly react to
topological changes for two main reasons. First, a node must ensure
that it is not isolated from other nodes sharing the same prefix that
it decided to use. This property is known in this document as prefix
continuity. Second, a node must be able to detect that it has lost
connectivity with its upstream neighbor.
4.1 Proactive protocols
Proactive protocols already provide a way to detect close topological
changes via the periodical sending of HELLO messages. We therefore
propose to use HELLO messages to send the GW_INFO information (as
part of the proactive protocol operation - if this is not possible,
the same method described for reactive protocols SHOULD be used). In
particular and with this method, it is possible for a node to detect
a loss of connectivity with one of its neighbor and to know what
prefix is used by each of its neighbors. The GW_INFO message MAY be
sent in each HELLO packet sent by a given node. However, to reduce
the induced overhead, a node MAY only add the GW_INFO message to its
HELLO packets when a new neighbor appears or when there is a change
in the GW_INFO information it maintains. When the overhead reduction
mechanism is used, a node SHOULD still include a GW_INFO message once
every GW_INFO_MIN_REFRESH HELLO packets transmitted. In all cases
with overhead reduction, a node which decides to include GW_INFO
information in its upcoming HELLO packet MUST also include the
(possibly updated) GW_INFO information in its next HELLO packet to
prevent information loss if a packet collision/loss occurs.
4.2 Reactive protocols
Reactive protocols do not (strictly) use a HELLO-like mechanism to
maintain a knowledge of their neighborhood. However, our proposed
method needs a periodical exchange of GW_INFO messages. A node using
a reactive routing protocol MUST therefore send every
GW_INFO_REFRESH_PERIOD a packet containing a GW_INFO message. The
IPv6 destination address of this packet MUST be ff02::1 and the hop
limit field in the IPv6 header MUST be set to 1. The IPv6 source
address of such a packet SHOULD be the IPv6 link local address of the
sender. This packet can be sent by the reactive protocol itself (as
part of its normal operation) or it can be sent by a parallel
stand-alone process (i.e. a daemon in networking terms). The same
assumption applies for the reception of such packets. In the rest of
this document, such a packet containing a GW_INFO message will be
called a GW_INFO packet.
Jelger & Noel Expires February 25, 2004 [Page 8]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
Each node should maintain and update a list of pairs of the form
(SRC_ADDR ; PREFIX) for each GW_INFO packet received. SRC_ADDR is the
source address of the IPv6 header of the GW_INFO packet and PREFIX is
the IPv6 prefix contained in the GW_INFO message. This list allows a
node to check if it does not become isolated from nodes which share
the same prefix that it uses. Also, the periodicity introduced in the
sending of GW_INFO packets allows a node to update the 3-bit "Link"
field of the GW_INFO messages it sends. This is detailed in Section
5.
We also believe that there is no need for a node to keep a default
entry in its routing table when a reactive routing protocol is used.
This is in contrast to what is proposed in [5]. Keeping a default
route is somehow contradictory with the reactive nature of such
protocols, i.e. a route request is started when a node cannot find a
route to a destination with which it wishes to communicate. The
default route prevents the route discovery procedure to happen.
Moreover, the presence of a gateway is not contradictory with the
reactive nature of such protocols. A node wishing to communicate with
a node outside the adhoc network generates a route request and,
according to these protocols, the first node with a fresh enough
route can reply. In the worst case, the gateway can therefore send
the route reply indicating that it has a route to the destination.
Jelger & Noel Expires February 25, 2004 [Page 9]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
5. Detailed mode of operation
This section gives a detailed description of the mode of operation of
our proposed protocol. We first detail the hop-by-hop propagation of
the GW_INFO information and how this information is used by a node to
create a global address and (with proactive protocols) to add a
default route. We then explain the use of sequence numbers to avoid
the propagation of false information after nodes movements. Third, we
describe the use of the "Link" field of the GW_INFO message. It is
used by a node to notify its neighbors about the "freshness" of the
information contained in its GW_INFO message. Finally in a fourth
sub-section, we detail the algorithms used by a node to select and
update its prefix and gateway information.
5.1 Hop-by-hop propagation of GW_INFO messages
GW_INFO messages propagate in a hop-by-hop manner, starting from a
gateway and propagating away from it. A node can receive multiple
GW_INFO messages depending on the network topology and on the number
of gateways in the network. A node MUST follow the algorithms
described in Section 5.4 to select and update the prefix and gateway
information. It MUST also use the selected information to build and
send its own GW_INFO messages. In short, a node selects, among all
the GW_INFO messages received within an arbitrary started
GW_INFO_REFRESH_PERIOD period, the most appropriate GW_INFO message
according to the algorithms described in Section 5.4. The node B
which sent the GW_INFO message that has been selected by a node A
becomes the upstream neighbor of A. The node A uses the information
contained in the GW_INFO messages sent by node B to create and send
its own GW_INFO messages. In particular, the "distance" field (d)
contained in its own GW_INFO messages MUST be equal to the "distance"
field (s) of the selected GW_INFO message plus one (d=s+1). This
field MUST be set to zero by a gateway. Also, a node MUST use in its
GW_INFO messages the same "Gateway Global Address" field as the one
present in the GW_INFO message it has selected. The same rule applies
for the "Prefix Length" and the "Sequence Number" fields, i.e. they
are left unchanged.
5.2 Avoiding confusion after nodes movements
The changing nature of the topology of an adhoc network requires that
a mechanism must be used to prevent a node from accepting wrong or
outdated information after nodes movements. We borrow the concept
from the DSDV routing protocol [6], a distance vector protocol which
uses sequence numbers to avoid the dissemination of wrong routing
information.
In our proposal, a gateway adds a sequence number in each of its
Jelger & Noel Expires February 25, 2004 [Page 10]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
GW_INFO messages. This sequence number MUST be increased by one each
time a GW_INFO message is sent by the gateway. When started, a
gateway SHOULD use a sequence number initial value equal to zero. A
node which decides to use the GW_INFO information of a given node (in
order to build its own GW_INFO messages) MUST use the same sequence
number (in its GW_INFO messages) as the one contained in the GW_INFO
message it has selected. Each node stores the GW_INFO information in
current use and, for a given gateway, can therefore compare the
sequence number it has against the sequence number in received
GW_INFO messages. For a given gateway, a node MUST NOT use the
information contained in a GW_INFO message if the sequence number it
contains is smaller or equal to the one stored by the node. The only
exception to this rule is if the sequence number is equal to zero :
in this case, it MUST not be compared with the stored information (if
available).
5.3 GW_INFO information freshness notification
In order to ease the selection procedure used by a node to choose the
neighbor from which it takes the GW_INFO information, we propose to
add information about the freshness of such information. GW_INFO
messages are indeed sent at periodical intervals, and a node can
therefore expect to receive GW_INFO messages from its upstream
neighbor at fixed and known intervals. It can thus detect if it has
not received an expected GW_INFO message. We propose that each node
indicates in its GW_INFO messages if it has not received one or more
GW_INFO messages from its upstream neighbor. The "Link" field of the
GW_INFO message is used for this purpose. The 3 bits of this field
have the following meaning. The K bit, when set to one, indicates
that a node has not received the last expected GW_INFO from its
upstream neighbor. In the following GW_INFO message sent by the node,
the value of the K bit of the previous GW_INFO message sent MUST be
copied to the N bit, and the value of the N bit of the previous
GW_INFO message sent MUST be copied to the L bit. The K bit must be
updated according to the method described above. The K bit therefore
gives an "instantaneous" image of the link quality towards the
upstream node, and in other terms, an idea of the freshness of the
information contained in the GW_INFO message. The other two bits (N
and L) reflect the evolution of the link quality. The three bits are
used in the selection algorithm (detailed in Section 5.4) used by a
node to choose its upstream neighbor.
5.4 Algorithms and node behaviour
This section describes the selection algorithms that are to be used
by a node receiving multiple GW_INFO messages in order to select the
upstream neighbor. The behaviour of a node is different whether it
already has a global address or not. Because no assumption can be
Jelger & Noel Expires February 25, 2004 [Page 11]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
made on the frequency of topological changes in an adhoc network,
preference is given to address stability rather than route
optimization. That is, a node must not change its global address
unless it has lost connectivity with other nodes sharing the same
prefix.
5.4.1 Initial selection algorithm
When a node does not have a global address, it should wait until it
receives a GW_INFO message. Upon reception of a GW_INFO message, it
SHOULD wait GW_INFO_REFRESH_PERIOD to ensure that there are no other
neighbors sending GW_INFO messages. If only one GW_INFO message is
received, the sender of this message is chosen as the upstream node.
The information contained in the GW_INFO message is used as defined
in the next paragraph. If multiple GW_INFO messages are received, the
selection is done as follows. All GW_INFO messages received are
grouped (in sets) according to the prefix they contain. Let d be an
integer value initially set to zero. The prefix of the set that
contains the most GW_INFO messages with the "distance" field equal to
d is selected. If more than one set have an equal number of entries
with a "distance" field equal to d, d is increased by one and the
test is re-applied, but only on the sets that were in the tie. This
procedure is repeated until a set can be selected. If this test does
not permit to select a set, a new test must be applied to the sets
that remained in the last tie. The value d is again set to zero, but
this time the "Link" value is checked. The value is computed as v =
K^3+N^2+L (where x^y means x to the power of y) for each GW_INFO
message. For a given set and a given value of d, a value g is
computed as the sum of all v values of the entries that have a
"distance" equal to d. The set with the smallest value of g is
selected. If a set cannot be selected, d is increased by one and the
same test is re-applied to the sets that remainded in the last tie.
If, after the last check, no set is selected, one must be randomly
chosen among the sets remaining in the last tie. Finally and within
the selected set, the entry with the smallest "Link" value among
those with the smallest "distance" value is chosen. If a tie remains
it is broken via a random choice.
The prefix contained in the selected GW_INFO message is used to
create a global address by adding the node's EUI to the prefix, as
done for the link local address with the fe80::/64 prefix. Note that
it is preferable if gateways announce a /64 prefix. If this not the
case, the prefix must be padded with zeros until a length of /64 is
reached. The normal DAD (Duplicate Address Detection) of the IPv6
protocol MUST NOT be performed, because the probability of an address
collision is very low when EUI are used, and DAD is also complex to
setup in an adhoc network. The information contained in the GW_INFO
message (noted o) of its upstream node is also used by a node to
Jelger & Noel Expires February 25, 2004 [Page 12]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
create its own GW_INFO message (noted n). The value of the "distance"
field of n is equal to the value of the "distance" field of o plus
one. The G bit of n MUST be set to zero. All other fields are left
unchanged.
With proactive protocols, a default route entry is also added to the
node's routing table. The upstream node becomes the next hop for the
default entry.
default/0 upstream_node
This is in contrast to the method proposed in [5] to add a default
entry such as :
default/0 gateway
gateway/128 upstream_node
The problem with the work from [5] is that it requires the
possibility for the operating system to perform a double (or
recursive) routing table lookup, something that is currently not
implemented in modern operating systems. If this feature becomes
available, this method SHOULD be prefered.
5.4.2 Maintaining prefix and route information
When a node already has a global address set, it should continue to
listen to updated GW_INFO messages from its neighbors. In particular,
it should update its stored information (i.e. prefix, gateway address
and distance), and is allowed to decide to choose a new upstream
neighbor but ONLY, and only if the prefix remains identical. With
proactive protocols, a change in the upstream neighbor also triggers
an update in the routing table. A node decides to choose a new
upstream neighbor if it receives GW_INFO messages with a smaller
"distance" field than what is sent by the current upstream node, at
the condition that the "Link" field is equal or better than the one
in use. A node MUST choose a new upstream neighbor if it has not
received LINK_LOST consecutive GW_INFO messages from its upstream
neighbor.
The only situation in which a node is allowed to change its prefix
(and consequently its global address) is if this node loses
connectivity with all its neighbors which shared the same prefix. By
losing connectivity, we mean that either these nodes are not
reachable (LINK_LOST consecutive GW_INFO messages are not received),
or that the "Link" field of their GW_INFO messages is equal to 111
(in binary representation), which means that the node sending the
GW_INFO message has lost connectivity with its upstream node. If
these conditions are satisfied, a node is allowed to choose a new
Jelger & Noel Expires February 25, 2004 [Page 13]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
upstream neighbor with a new prefix. In that case, the global address
of the node MUST be changed accordingly. With proactive protocols,
this also triggers an update in the routing table. The old global
address MUST be removed. It is also possible to use a protocol such
as Mobile IPv6 to maintain connectivity at the transport layer but
this is out of the scope of thios ducument.
Because of the frequent update imposed by the use of GW_INFO
messages, there is no prefix lifetime value within a GW_INFO message.
When a node configures a global address it SHOULD set a lifetime
value at least greater than GW_INFO_REFRESH_PERIOD*LINK_LOST.
However, a node which has lost connectivity with all its neighbors
SHOULD remove its current global address and all GW_INFO information
associated to it.
Jelger & Noel Expires February 25, 2004 [Page 14]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
6. DNS considerations
As an extension to the proposed protocol, DNS information could also
be sent in GW_INFO messages. This would allow a node to select a
gateway that also permits to reach a DNS server. The GW_INFO
extension could be easily extended to include a field which contains
the IPv6 global address of a DNS server, as shown in Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next header | Hdr Ext Len | Option type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Distance |G|L N K| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Gateway Global Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS server Global Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Extended GW_INFO message format
With this new message format, the "Hdr Ext Len" field MUST be set to
4, and the "Opt Data Len" must be set to 36.
Jelger & Noel Expires February 25, 2004 [Page 15]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
7. Protocol parameters values
GW_INFO_MIN_REFRESH 10
GW_INFO_REFRESH_PERIOD 2 seconds
LINK_LOST 3
8. Acknowledgements
The authors wish to thank Prof. Jean-Jacques Pansiot for his helpful
comments and suggestions concerning the use of the "Link" field.
Jelger & Noel Expires February 25, 2004 [Page 16]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
References
[1] Perkins, C., Eli, E. and S. Das, "Ad hoc On-Demand Distance
Vector (AODV) Routing", RFC 3561, July 2003.
[2] Johnson, D., Maltz, D. and Y. Hu, "The Dynamic Source Routing
Protocol for Mobile Ad Hoc Networks (DSR)", I-D
draft-ietf-manet-dsr-09.txt, April 2003.
[3] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol", I-D draft-ietf-manet-olsr-11.txt, June 2003.
[4] Ogier, R., Templin, F. and M. Lewis, "Topology Dissemination
Based on Reverse-Path Forwarding (TBRPF)", I-D
draft-ietf-manet-tbrpf-10.txt, July 2003.
[5] Wakikawa, R., Malinen, J., Perkins, C., Nilsson, A. and A.
Tuominen, "MIPv6 for Multiple Interfaces", I-D
draft-wakikawa-manet-globalv6-02.txt, November 2002.
[6] Perkins, C. and P. Bhagwat, "Highly Dynamic
Destination-Sequenced Distance-Vector Routing ({DSDV}) for
Mobile Computers", November 1994.
Authors' Addresses
Christophe Jelger
LSIIT - Universit‰ Louis Pasteur
Pźle API, bureau C429
Boulevard S‰bastien Brant
Illkirch 67400
FRANCE
Phone: +33 390 24 45 90
EMail: jelger@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~jelger/
Jelger & Noel Expires February 25, 2004 [Page 17]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
Thomas Noel
LSIIT - Universit‰ Louis Pasteur
Pźle API, bureau C428
Boulevard S‰bastien Brant
Illkirch 67400
FRANCE
Phone: +33 390 24 45 92
EMail: noel@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~noel/
Jelger & Noel Expires February 25, 2004 [Page 18]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Jelger & Noel Expires February 25, 2004 [Page 19]
Internet-Draft Adhoc gateway/prefix autoconf August 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jelger & Noel Expires February 25, 2004 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 15:20:24 |