One document matched: draft-funato-seamoby-gaard-01.txt
Differences from draft-funato-seamoby-gaard-00.txt
Seamoby Working Group Daichi Funato
Internet Draft Xiaoning He
draft-funato-seamoby-gaard-01.txt Carl Williams
Expires: December 24, 2002 Atsushi Takeshita
June 2002 DoCoMo USA Labs
Mohammed D. Ali
Juana Nakfour
Motorola
Geographically Adjacent Access Router Discovery Protocol
<draft-funato-seamoby-gaard-01.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 obsolete 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.''
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
The internet-draft will expire in 6 months. The date of expiration will
be December 24, 2002.
ABSTRACT
This document describes a scheme that allows a node to determine an IP
address corresponding to a given link-layer id. The node performing the
query doesn't need to be on the same link or subnet of the node
associated with the link-layer id. This scheme was designed for the
handoff candidate access router discovery in wireless networks, but may
also be applied to other networks with similar behavior.
Funato, et. al. Expires December 24, 2002 [Page 1]
Internet-Draft GAARD June, 2002
Table of Contents
1. Introduction.................................................... 3
2. Problem Statement and Solution.................................. 3
2.1 Terminology................................................. 4
3. GAARD Protocol Overview......................................... 5
4. GAARD Inverse Neighbor Discovery Process........................ 6
4.1 Mobile Node and Current Access Router Process............... 6
4.1.1 Mobile Node............................................. 7
4.1.2 Current Access Router................................... 7
4.2 GAARD Inverse Neighbor Discovery ........................... 7
4.3 GAARD Inverse Neighbor Advertisement........................ 9
4.4 GAARD Inverse Neighbor Discovery/Advertisement Option
Field Format................................................11
4.4.1 Link-Layer Address Field................................11
4.4.2 Target AR IP Address Field..............................12
4.4.3 Cache Update Field......................................13
4.5 GAARD Address Resolution for IPv4..............................13
4.6 Access Router Cache Lifetime...................................14
5. GAARD Cross-Link Neighbor Discovery Protocol....................14
5.1 GAARD SLP Messages..........................................15
6. Security........................................................16
7. References......................................................16
8. Authors' Addresses..............................................17
9. IPR Statement...................................................18
10.Acknowledgements................................................18
Funato, et. al. Expires December 24, 2002 [Page 2]
Internet-Draft GAARD June, 2002
1. Introduction
In a wireless network, handover occurs when a mobile node moves from the
current access point to a geographically adjacent access point. For each
geographically adjacent access point, if they are connected to different
access routers, these access routers are defined as Geographically
Adjacent Access Routers (GAARs).
This document describes a scheme that discovers a GAAR's IP address from
a given link-layer id. The proposal is modeled after the Reverse Address
Resolution Protocol [1] for IPv4 and Inverse Neighbor Discovery [2],[3]
for IPv6. The key difference is that the target GAAR corresponding to
the link-layer id may reside on a different link or in a different
subnet relative to the node making the query.
A high-level description of the Geographically Adjacent Access Router
Discovery (GAARD) protocol can be applied to many applications including
candidate access router (CAR) discovery to find the IP address of the
handoff candidate access router that a mobile node may move to [15].
This ability may help facilitate functionality in fast handovers schemes
(e.g., Fast MobileIPv6 [10]).
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL,
SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in [18].
2. Problem Statement and Solution
For real-time mobile applications, smooth and fast handover is critical.
Furthermore, for most fast hand-over schemes, it is important for the
mobile node and the current access router to be aware of the IP
addresses of its GAARs. However, finding a GAAR's IP address is not that
easy because those GAARs may be located in different links or subnets.
A conventional solution is to manually configure this geographical
neighborhood at each access router. However, such an approach requires
human intervention and may not be feasible in large scale wireless
networks. Another solution is based on special location information
system such as GPS (Global Positioning System). However, GPS is not
always available in many cases.
Due to these facts, it is clear that an automatic and dynamic mechanism
is required to discover GAARs without much administrative intervention.
In the rest of this document, the GAARD protocol is presented.
The GAARD is accomplished through a distributed process whereby a mobile
node associated with the current access router identifies the next
access router by getting the link-layer id of the access point
Funato, et. al. Expires December 24, 2002 [Page 3]
Internet-Draft GAARD June, 2002
associated with the next access router. The process of getting the
access point link-layer id is dependent on the wireless network. One
approach would be for the mobile node to listen to link-layer ids in
beacons using a L2-L3 interface mechanism, such as [4].
The GAARD then specifies a mechanism whereby the current access router
resolves a mapping to the IP address associated with the link-layer id.
In this case it would be the interface IP address of the next access
router associated with the new access point. The current access router
would process the mapping queries from the mobile node. As the mapping
query is for a node that resides different link relative to the mobile
node making the request, this cross-link resolution is achieved by using
the Service Location Protocol [14] based approach. Once the current
access router is able to resolve the L2-L3 mapping, it can respond to
the mobile node with the resolved IP address.
To save time on future resolutions, the mapping information can be
stored in the current access router as a cache for later use, which was
also proposed in [5] and [6]. However, there should be no special
network topological semantics associated with the cache. It is expected
that this cache will be small and entries will obviously have a lifetime.
The mobile node may also maintain a temporary cache of the L2-L3
mappings with a lifetime associated with each entry.
In this respect the mobile node functions as an L2 sensor for
identifying next handoff access routers in order to acquire L3
information to perform seamless IP-level handovers, such as fast
handover [10] and context transfer [11].
It is thought that the model above provides a query-response scheme
similar to that of RARP and Inverse ND. There is no network topological
state that is retained or requested. The mechanism ONLY seeks to map an
L2 identifier to an L3 identifier for a node that resides on a different
link or subnet from the node requesting the information. There are no
special semantics associated with a cache that a router/node may
maintain to execute the mapping queries on behalf of nodes on its links.
This GAARD protocol is just one generic mechanism that applications such
as FMIPv6 can use to accomplish their overall goals. We contend that
this proposal is a generic tool that is not specific to candidate access
router discovery but can be used in any scenario that involves a node
requesting L2-L3 mapping for a node that resides off-link.
2.1 Terminology
-Mobile Node (MN)
A Mobile Node is an IP host capable of moving its point of
attachment to the Internet.
Funato, et. al. Expires December 24, 2002 [Page 4]
Internet-Draft GAARD June, 2002
-Access Point (AP)
An Access Point is a first-hop link-layer radio device between the
Access Router and the Mobile Node by which a Mobile Node obtains
Layer 2 connectivity with the wired network.
-Access Router (AR)
An Access Router is the last IP router between the access network
and the Mobile Node. An Access Router is connected to one or more
Access Points and offers IP connectivity to a Mobile Node.
-Geographically Adjacent Access Router (GAAR)
An AR whose coverage area is such that an MN may move from
the coverage area of the AR currently serving the MN into the
coverage area of this AR. In other words, GAARs have APs whose
coverage areas are geographically adjacent or overlap.
3. GAARD Protocol Overview
~~~~~~~~~~~
{ }
{ }
+----------{ IP Cloud }-----------+
GAARD SLP |+--------->{ }<----------+|
Service || GAARD { } ||
Reply || SLP ~~~~~~~~~~~ ||
V| Service Request |V AR IP addr.
+---------+ +---------+
| Current | | Next |
| AR | | AR |
+---------+ +---------+
GAARD ^| GAARD AR L2 addr.| | AR L2 addr.
Inverse || Inverse | |
Neighbor || Neighbor | |
Discovery |V Advertisement +---+ +---+
+--------------+ AP L2 id +--|AP1| |AP2|
| Mobile |<---------------------+ +---+ +---+
| Node |<--------------------------------|
+--------------+ AP L2 id
Figure.1 GAARD Protocol Overview
In short, the GAARD protocol intends to allow a mobile node to resolve
the IP address of the GAAR across different subnets based on link-layer
id. Since the protocol such as RARP can only resolve the IP address
within a subnet, it is necessary to develop a protocol such as the GAARD
Funato, et. al. Expires December 24, 2002 [Page 5]
Internet-Draft GAARD June, 2002
protocol presented in this draft to resolve the IP address based on
link-layer id across multiple subnets.
In GAARD protocol, the wireless network MUST provide some mechanism
where the mobile node can maintain the list of current link-layer ids of
surrounding access points. One approach would be to broadcast the link-
layer id in a link-layer beacon. An alternate approach for IEEE 802.11
networks is a mobile node can actually send a management frame subtype
probe request and collect all the probe responses to build a link-layer
id list of potential handoff access points from the surrounding Access
Points which is much more efficient then actively listening to all
beacons. This approach also has the advantage of acquiring a list of
candidate handoff access points and possibly minimizing security threat
of listening to flooding beacons from a bad access point. The link-layer
ids MUST be unique.
Furthermore, the access router MUST maintain a list of link-layer ids
and the IP address of the interface the access point is associated with
on that access router, each entry must have a lifetime associated with
it. When the Mobile Node receives a new link-layer id, it sends the
Inverse Neighbor Discovery message carrying this link-layer id to its
current access router.
At each access router, a GAARD cache defined in section 4.5 should be
maintained. Each cache entry contains the link-layer id, the IP
addresses associated with this id and the lifetime.
If the IP address associated with link-layer id received from the GAARD
Inverse Neighbor Discovery message is found in the cache, the GAARD
Inverse Neighbor Advertisement message, which carries these IP address,
will be sent back to the Mobile Node. Otherwise, the GAARD protocol will
attempt to resolve the IP address first. As defined in section 5, the
Service Location Protocol (SLP) will be used to resolve the IP address
based on the link-layer id across multiple subnets.
4. GAARD Inverse Discovery Process
4.1 Mobile Node and Current Access Router Process
For the different IP versions, the messages between mobile node and
current access router are defined separately. For IPv6, the messages are
defined as the extensions of Inverse Neighbor Discovery messages [2] in
section 4.2 and 4.3. For IPv4, the message can be defined as the
extensions of Reverse Address Resolution Protocol [1].
Funato, et. al. Expires December 24, 2002 [Page 6]
Internet-Draft GAARD June, 2002
4.1.1 Mobile Node
On the mobile node, GAARD can be implemented in two ways: Active mode
and Silent mode. Active mode is when GAARD is actively looking for new
AP link-layer ids and maintains a cache of L2-L3 mapping of all
surrounding APs, in this case any application interested in an L2-L3
mapping can just access this cache. Silent mode is when GAARD is only
invoked by an application that needs the mapping of a link-layer id to a
Layer 3 address, in this case GAARD provides an API for applications to
use.
When a mobile node receives a new link-layer id, the mobile node MUST
format a GAARD Inverse Neighbor Discovery message as defined in section
4.2 and sends it to the current access router. The current access router
will respond by sending back the GAARD Inverse Neighbor Advertisement
message, which contains the IP addresses, associated with the Link-layer
id. GAARD can either be in the active mode and update the cache or be in
the silent mode and forward the L2-L3 mapping to the application.
4.1.2 Current Access Router
After the GAARD Inverse Neighbor Discovery message is received, the
receiving node, i.e. current access router, checks the Target Link-Layer
Id field. If the Target Link-Layer Id field is null, then the receiving
node MUST send all the cache data.
If the fields is not NULL and the IP addresses associated with the
Target Link-Layer Id is found in the cache, the access router MUST
format a GAARD Inverse Neighbor Advertisement message and send it back
to the sender.
If the IP addresses associated with the Target Link-Layer Id in the
GAARD Inverse Neighbor Discovery message cannot be found in the cache,
the GAARD SLP process defined in section 5 MUST be performed by the
current access router.
4.2 GAARD Inverse Neighbor Discovery
A mobile node sends a GAARD Inverse Neighbor Discovery message, which
carries the Target Link-Layer Id, which was obtained from link-layer's
beacon or such, to its current access router.
The GAARD Inverse Neighbor Discovery message is defined as an extension
of the Inverse Neighbor Discovery message.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Funato, et. al. Expires December 24, 2002 [Page 7]
Internet-Draft GAARD June, 2002
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
An IPv6 address assigned to the interface from which this message
is sent.
Destination Address
The IPv6 address of Current Access Router
Hop Limit 255
Authentication Header
If a Security Association for the IP Authentication Header exists
between the sender and the destination address, then the sender
SHOULD include this header.
ICMP Fields:
Type TBD
Code 0
Checksum The ICMP checksum. See [9].
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Required options:
The sender node MUST send one or more following options in the GAARD
Inverse Neighbor Discovery message:
Source Link-Layer Id
The link-layer address of the sender.
Target Link-Layer Id
The link-layer address of the target.
Other valid options:
MTU
The MTU configured for this link [8].
Funato, et. al. Expires December 24, 2002 [Page 8]
Internet-Draft GAARD June, 2002
Future versions of this protocol may add other option types.
Receivers MUST silently ignore any options they do not recognize and
continue processing the message.
4.3 GAARD Inverse Neighbor Advertisement
After receiving the GAARD Inverse Neighbor Discovery message, the
current access router replies with the GAARD Inverse Neighbor
Advertisement.
If the Target Link-Layer Id field in the GAARD Inverse Neighbor
Discovery message is not NULL and a cache entry is found which contains
the IP address associated with the link-layer id carried in the GAARD
Inverse Neighbor Discovery message or the GAARD SLP Process as defined
in Section 5 is successfully being performed, the access router MUST
send back this cache entry to the Mobile Node.
The GAARD Router Advertisement message is defined as an extension of the
Inverse Neighbor Advertisement message:
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
The address of current access router which is assigned to the
interface from which the advertisement is sent.
Destination Address
The Source Address of Mobile Node, which invoked Inverse Neighbor
Discovery Solicitation.
Hop Limit 255
Authentication Header
If a Security Association for the IP Authentication Header [16]
exists between the sender and the destination address, then the
sender SHOULD include this header.
ICMP Fields:
Funato, et. al. Expires December 24, 2002 [Page 9]
Internet-Draft GAARD June, 2002
Type TBD
Code 0
Checksum The ICMP checksum. See [9]
Reserved 32-bit unused field. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Required options:
The sender node MUST send one or more following options in the
GAARD Inverse Neighbor Advertisement message:
Source Link-Layer Id
The link-layer address of the sender.
Target AP Link-Layer Id
The link-layer id of the target access point, that is, the
link-layer address carried in the GAARD Inverse Neighbor
Discovery message.
Target AR Link-Layer Id
The link-layer address of the target access router. It may be a
wired interface's link-layer id.
Target AR IP Address
The list of one or more IP address associated with the AP's
link-layer id along with the lifetime associated with each IP
address. The lifetime defines the time of expiry in seconds and
is refreshed whenever a GAARD Cross-Link Discovery message in
section 5 is received for the corresponding access router.
Other valid options:
The format of this field in defined in Section 4.4.
The sender node MAY choose to add the following option in the
Advertisement message:
MTU
The MTU configured for this link.
Future versions of this protocol may add other option types.
Receivers MUST silently ignore any options they do not recognize and
continue processing the message.
Funato, et. al. Expires December 24, 2002 [Page 10]
Internet-Draft GAARD June, 2002
4.4 GAARD Inverse Discovery/Advertisement Option Field Format
In section 4.2 and 4.3, the Inverse Neighbor Solicitation/Advertisement
messages are being used. However, different from usage of Inverse
Discovery/Advertisement message, some optional fields are mandatory in
GAARD. Also, a new optional field, i.e. Cache Update is defined.
4.4.1 Link-Layer Id Field
This extension is based on the TLV format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Length | Media-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Sub-Type
TBD
(tentative: 1 for Source Link-Layer Address)
(tentative: 2 for Target AP Link-Layer Id)
(tentative: 3 for Target AR Link-Layer Id)
Length
The length of the option (including the type, sub-type and
length fields) in units of 8 octets.
Media-Type
TBD
For the link-layer id identifying the access technology,
such as radio access types of the link-layer beacon.
e.g. 802.11b
LLID
The variable length link-layer id or address.
The content and format of this field (including byte and bit
ordering) is expected to be specified in specific documents
that describe how IPv6 operates over different link layers.
Funato, et. al. Expires December 24, 2002 [Page 11]
Internet-Draft GAARD June, 2002
4.4.2 Target AR IP Addresses Field
This extension is based on the TLV format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Length | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target IP Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Sub-Type
TBD
(tentative: 3 for Source Address)
(tentative: 4 for Target Address)
Length
The length of the option (including the type, sub-type and
length fields) in units of 8 octets.
Lifetime
16-bit unsigned integer. The lifetime associated with the L2-
L3 mapping.
Target IP Address
The IPv6 address of the interface on which the AP with the
link-layer id is associated with.
Funato, et. al. Expires December 24, 2002 [Page 12]
Internet-Draft GAARD June, 2002
4.4.3 Cache Update Field
When a cache entry at the access router has been changed or deleted, the
current Access Router MUST broadcast the GAARD Cache Update message
within the link.
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Fields:
Type TBD
Code 0
Length The Length of the cache update message
AC Action of the Update
0 Update an entry
1 Remove an entry
Reserved 32-bit unused field. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Required options:
TBD
Other valid options:
TBD
Future versions of this protocol may add other option types.
When the AC field is set to be 0, the Mobile Node MUST update the
entry with the information carried in the GAARD Cache Update message.
When the AC field is set to be 1, the Mobile Node MUST remove
the entry.
4.5 GAARD Address Resolution for IPv4
TBD
Funato, et. al. Expires December 24, 2002 [Page 13]
Internet-Draft GAARD June, 2002
4.6 Access Router Cache Lifetime
Each GAARD access router MAY maintain a cache table. The cache entry
MUST have lifetime in order to keep the cache coherency. It defines the
time of expiry in seconds. This field is refreshed whenever a GAARD
Cross-Link Discovery message in section 5 is received for the
corresponding access router.
5. GAARD Cross-Link Neighbor Discovery Protocol
In order to resolve the GAAR's IP address across multiple subnets,
the Service Location Protocol (SLP) [14] can be used in the GAARD
protocol. Inter-Administrative Domain Discovery is not covered in this
draft and may be covered in the following drafts.
At each access router, a list which contains the link-layer id of the
access points connected to it along with the interface IP address to
which that access point is connected MUST be maintained. If a SLP DA is
deployed, the access router MUST format and send a service
registration message (ServReg) which contains both IP address of the
access router interface and the link-layer id list to the Directory
Agent (DA) in its scope periodically. If there is no deployed DA, the
access router MUST function as a SLP Service Agent (SA) and service any
queries for the reverse address resolution.
After the access router receives the GAARD Inverse Neighbor Discovery
message from the mobile node and if the IP address associated with the
link-layer id is not found in the cache, the access router MUST format a
Service Request (ServReq) message which queries the IP addresses
associated with the link-layer id.
For example, when the current access router has to resolve the IP
address associated with the access point link-layer id = XXXX, it MUST
function as a SLP User Agent (UA) and format and send the following
ServReq message
<service:gaard;(link-layer-ap-id=XXXX)>
After receiving the Service Request message mentioned above, either the
DA or the access router which is a SLP SA in conformance with the SLP
specification MUST reply with a Service Reply message.
For example, the access router who is connected to the access point with
link-layer-ap-id is XXXX must send back the Service Reply message shown
as follows
<service:gaard://(host);ap-link-layer-id=XXXX;ar-link-layer-id=XXXX;
ip-addr=YYYY>
Funato, et. al. Expires December 24, 2002 [Page 14]
Internet-Draft GAARD June, 2002
This is only a brief overview of how SLP is used in GAARD protocol to
achieve cross subnet address resolution. The new SLP templates and
attributes defined for the GAARP will be described in other drafts.
5.1 GAARD SLP Messages
The following SLP service template identifies the messages, which are
used in GAARD Cross-Link Neighbor Discovery.
---------------------------------------------------------------------
template-type = gaard
template-version = 0.0
template-language = en
template-description = This is the service template for GAARD
template-url-syntax=
url-path = gaard://host [":" port ]
port = 1*digit
host = hostname / ip-addr
ip-addr = ipv4-number | ipv6-number
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
ipv6-number = ;See RFC 2373 [12] Section 2.2
hostname = *( domainlabel ".") toplabel
domainlabel = alphanum / alphanum * [alphanum / "-"] alphanum
toplabel = alpha / alpha * [alphanum / "-"] alphanum
# The AP link-layer types
ap-ll-type = STRING L X
TBD
# The AR link-layer types
ap-ll-type = STRING L X
TBD
# Literal description in the AP Link-Layer Id
ap-ll-id = STRING L X
# Literal description in the AR Link-Layer Id
ar-ll-id = STRING L X
# Message lifetime in seconds
lifetime = INTEGER
65535
# These options are used for IPv6 address auto-configuration.
Ipv6_network_prefix = STRING M O
Ipv6_network_prefix_length = INTEGER M O
Ipv6_preffered_lifetime = INTEGER O
Ipv6_valid_lifetime = INTEGER O
----------------------------------------------------------------------
Funato, et. al. Expires December 24, 2002 [Page 15]
Internet-Draft GAARD June, 2002
6. Security
GAARD Neighbor Solicitation and Neighbor Advertisement packet exchanges
can be authenticated using the IP Authentication Header[16]. A node
SHOULD include an Authentication Header when sending GAARD Neighbor
Solicitation and Neighbor Advertisement packets if a security
association for use with the IP Authentication Header exists for the
destination address. The security associations may have been created
through manual configuration or through the operation of some key
distribution protocol.
For the GAARD SLP process, SLPv2 provides an authentication mechanism
for UAs to assure that service advertisements only come from trusted SAs
[14]. If trust is an issue, then SLPv2 authentication should be enabled
in the network.
It SHOULD be possible for the system administrator to configure a node
to ignore any GAARD Protocol messages that are not authenticated using
either the Authentication Header or Encapsulating Security Payload. Such
a switch SHOULD default to allowing unauthenticated messages.
Confidentiality issues are addressed by the IP Security Architecture and
the IP Encapsulating Security Payload documents [16], [17].
7. References
[1] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse
Address Resolution Protocol", STD 38, RFC 903, June 1984.
[2] Conta, A. "Extensions to IPv6 Neighbor Discovery for Inverse
Discovery Specification", RFC 3122, June 2001
[3] Bradley, T., Brown, C. and A. Malis "Inverse Address Resolution
Protocol", RFC 2390, August 1998.
[4] Kempf, J., Funato, D., Malki, K., Gwon, Y., Pettersson, M.
Reoberts, P., Soliman, H., Takeshita, A. and Yegin, A.,
"Requirements for Layer 2 Protocols to Support Optimized Handover
for IP Mobility ", Work in Progress, November 2001.
[5] Pagtzis, T. and Kristein, P., "A Framework for Proactive Mobility
in Mobile IPv6", Work in Progress, July 2001.
[6] Trossen, D., Krishnamurthi, G., Chaskar, H., Shim, E. And Gitlin,
R., "Protocol for Candidate Access Router Discovery for Seamless
IP-level Handovers", Work in progress, November, 2001.
Funato, et. al. Expires December 24, 2002 [Page 16]
Internet-Draft GAARD June, 2002
[7] Deering, S. and R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[8] Narten, T., Nordmark, E. and W. Simpson "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[9] Conta, A., and S. Deering "Internet Control Message Protocol for
the Internet Protocol Version 6", RFC 2463, December 1998.
[10] Dommety, G., Yegin, A., Perkins, C., Tsirtsis, G., El-Malki, K.
and Khalil, M., " Fast Handovers for Mobile IPv6 ", Work in
Progress, July 2001.
[11] Syed, H. et al. "General Requirements for Context Transfer", Work
in Progress, January 2002.
[12] Hinden, R. and Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
March 1994.
[14] Guttman, E., Perkins, C., Veizades, J. and Day, M., "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[15] Krishnamurthi, G. "Requirements for CAR Discovery Protocols",
work in Progress, May 2002.
[16] Atkinson, R. and S. Kent, "IP Authentication Header", RFC 2402,
December 1998.
[17] Atkinson, R. and S. Kent, "IP Encapsulating Security Protocol
(ESP)", RFC 2406, November 1998.
[18] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8. Authors' Addresses
Daichi Funato
NTT DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110, USA
Phone: +1 408-451-4736
EMail: funato@docomolabs-usa.com
Xiaoning He
NTT DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110, USA
Funato, et. al. Expires December 24, 2002 [Page 17]
Internet-Draft GAARD June, 2002
Phone: +1 408-451-4741
EMail: xiaoning@docomolabs-usa.com
Carl Williams
NTT DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110, USA
Phone: +1 408-451-1050
EMail: cralw@docomolabs-usa.com
Atsushi Takeshita
NTT DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110, USA
Phone: +1 408-451-4705
EMail: takeshita@docomolabs-usa.com
Mohammed D. Ali
NAT, Advanced Technology Group
Motorola, Inc.
1421 W Shure Dr,
Arlington Heights, IL 60004, USA
Phone: +1 847-632-5576
Email: MALI1@motorola.com
Juana Nakfour
NAT, Advanced Technology Group
Motorola, Inc.
1421 W Shure Dr,
Arlington Heights, IL 60004, USA
Phone: +1 847-435-8925
Email: juana.nakfour@motorola.com
9. IPR Statement
The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained
in this document. For more information consult the online list
of claimed rights.
10. Acknowledgements
Thanks to James Kempf, Alper Yegin, Youngjune Gwon and Fujio Watanabe of
DoCoMo Communications Laboratories USA, Inc and Theresa Than, Jiang Zhu
of Motorola, for their valuable discussion, comments and support.
Funato, et. al. Expires December 24, 2002 [Page 18]| PAFTECH AB 2003-2026 | 2026-04-23 19:56:34 |