Internet DRAFT - draft-kempf-mipshop-nhood-discovery
draft-kempf-mipshop-nhood-discovery
James Kempf
Internet Draft DoCoMo Labs USA
Document: draft-kempf-mipshop-nhood-discovery-00.txt Rajeev Koodli
Nokia Research
Center
Expires: December, 2005 June, 2005
NEighborhood Discovery (NED) for Wireless Networks
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.
Abstract
In wireless networks, there is a need to discover what types of
networks are around a particular node. This need arises both when a
node connects initially to a network and when a node needs to perform
handover. Characteristics such as type of wireless technology, service
provider, bandwidth availability, etc. may all be of interest in making
a network connection or handover decision. In addition, a mobile node
may require a mapping between the Layer 2 access point identifier and
IP link information such as the Mobile IPv4 foreign agent address, or
IPv6 access router address and subnet prefixes, so that the node can
configure itself for the new IP link prior to moving. This document
describes the Neighborhood information Elements Discovery (NED)
protocol, for representing information elements that contain
neighborhood information. The packet format presented in this document
is independent of transport so that multiple mobility protocols can
make use of it.
Table of Contents
1.0 Introduction.....................................................2
2.0 Previous Work....................................................3
Kempf & Koodli Expires December, 2005 [Page 1]
Internet Draft NED June, 2005
3.0 Potential Uses...................................................5
4.0 Neighborhood Discovery Protocol Overview.........................6
5.0 Protocol Messages................................................7
6.0 Security Considerations.........................................13
7.0 IANA Considerations.............................................13
8.0 Normative References............................................13
9.0 Informative References..........................................14
10.0 Author Information..............................................14
11.0 IPR Statements..................................................14
13. Disclaimer of Validity...........................................15
14. Copyright Notice.................................................15
1.0 Introduction
With wireless networks increasing in heterogeneity and availability,
nodes must be able to discover what types of network connectivity are
available to them. Example characteristics of a network that influence
whether a mobile node chooses to connect to that network include
whether the type of link technology matches one of the network
interface cards on the node, whether the user has credentials for
authenticating with the offered network service provider(s), or whether
the available bandwidth on the network matches what the node needs for
expected application use, etc. The connection decision might be an
initial decision, about whether to actually connect with the network,
or it might be a handover decision, about whether to switch to a new
network link type from an existing one.
An example of such a network available today is an 802.11 WLAN hotspot
network with multiple service providers sharing access points, and with
multiple types of 802.11 link service available (a, b, and g). The
hotspot network could additionally be overlaid on multiple wide-area
GPRS networks run by multiple different cellular carriers, some of whom
also offer service on the hotspot network. Perhaps the cellular
carriers also share UMTS base stations as they do with 802.11 access
points. In the future, the widespread availability of interfaces for
802.11 next generation networks, 802.16 WiMax, and 802.15 device
networks on laptops and portable devices may add to the complexity of
network choices facing a node and its user.
In addition, the ability of a wireless node to optimize handover at the
IP layer may require information on neighboring IP links prior to
handover. For example, the wireless node may require information on IP
link configuration information, such as the link layer address of the
access router, or it may require security information about the router,
such as a router certificate. This information can be used to
preconfigure the node for the new link prior to handover, and thereby
expedite handover by reducing the signaling needed to obtain
connectivity on the new link. If this information is not available to
the wireless node prior to handover, the performance of IP handover can
be severely impacted.
Kempf & Koodli Expires December 2005 [Page 2]
Internet Draft NED June, 2005
In this document, we describe a transport independent network
information representation format that allows a node to discover
information about surrounding networks using a suitable transport
protocol. The format is designed so that, like the Extensible
Authentication Protocol [RFC3748], it can be used over a Layer 2.5 as
well as a Layer 3 transport. The protocol can also be used between
network elements, such as routers, switches, and access points, to
exchange information about these IP links. Because the protocol allows
nodes to discover information about their neighborhoods between subnets
the framework is called the Neighborhood information Elements Discovery
(NED).
1.1 Terminology
Mobility related terminology is taken from RFC 3773 [RFC3773].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Additional terminology is the following:
IP link
A collection of IP nodes connected via a broadcast domain and
including routing capability to the Internet or an outside network.
In IPv4, this is often called a "subnet" but since IPv6 allows
multiple subnet prefixes to be assigned to a single link, the term
"IP link" is more accurate.
2.0 Previous Work
A majority of the network selection decisions today are based on three
criteria:
1) In an initial attachment scenario, does the node have an active
network interface card that can passively read or actively scan for
a beacon from an access point, and does that beacon contain Layer 2
network identifying information appropriate to the node? In 802.11
WLAN networks, the Layer 2 network identifying information is the
SSID.
2) In an initial attachment scenario, does the node have credentials
available to authenticate with one of the service providers offering
network access, and, if the node has credentials with more than one
service provider, which is the most appropriate for the user's task
set? These criteria involve decision making based on network access
authentication and are discussed in [EAPSEL].
3) In a handover scenario, which access point supporting the link
technology currently in use by the node exhibits the best signal
strength or other Layer 2 criteria for the node? For some wireless
link technologies and implementations, the measurement and handover
decision is embodied in the interface card firmware and not subject
to any involvement by higher layers in the network stack; while for
others, it is feasible for higher layer policy to control the
handover decision.
Kempf & Koodli Expires December 2005 [Page 3]
Internet Draft NED June, 2005
These criteria need to be contrasted with the design goals of this
document. 1) involves decision making that, while automated at a higher
level on some laptops today, nevertheless involves link layer criteria
of fairly limited semantic scope. 2) involves an initial authentication
decision that is determined by pre-configuration on the node and the
user's task set. 3) involves fast decision making at the link level
based on the characteristics of the wireless connection between the
node and access point that have nothing to do with higher level
criteria.
The existing experimental IETF protocols were developed to extend this
basic neighborhood discovery scenario to include the following two
functions:
1) Provide basic information whereby the L2 addresses of access points
in neighboring subnets obtained through "scans" can be resolved to
subnet information sufficient to pre-configure the wireless node for
the neighboring IP subnet. Such a pre-configuration can accelerate
IP handover. The pre-configured L2 information is typically the L2
address of an access router in the neighboring subnet, and the pre-
configured L3 information includes foreign agent address for Mobile
IPv4 [MIP4], subnet prefix for IPv6 [MIP6] in order to do address
auto-preconfiguration, or access router certificate for SEND [SEND]
to avoid having to obtain the certificate after handover.
2) Provide more advanced information about neighboring subnets that,
together with some policy constraints on the wireless node, guide
the handover decision-making. Examples of such information are the
identity of the service providers, cost of service, or available
bandwidth.
The three existing experimental IETF protocols are CARD [CARD], FMIPv6
[FMIP], and LLH [LLMIP].
The Seamoby Working Group developed a protocol called Candidate Access
Router Discovery [CARD] that is designed specifically to identify access
routers in surrounding networks by their access points. CARD addresses the
scenario where heterogeneous wireless networks are available, a wireless
node with a link to one of them is interested in finding out the types and
characteristics of links are available in its neighborhood for handover in
order to optimize handover. A wireless node solicits the information from
its access router. The node can either use the results of scans to request
the information by access point link layer address, or it can ask for a
comprehensive report of what types of links are available and their
characteristics. This information is used to select target access routers
for handover, and, when a candidate for handover is selected, a protocol
such as FMIP can be used to optimize the handover. The same information
format used between an access router and a wireless node can also be used
between access routers to allow an access router to develop a map of the
characteristics of networks in its neighborhood.
The Fast Mobile IPv6 [FMIP] protocol and the Low Latency Mobile IPv4 Handoff
protocol [LLMIP] provide messages that allow a wireless node to map an
access point's link address to the neighborhood subnet information including
Kempf & Koodli Expires December 2005 [Page 4]
Internet Draft NED June, 2005
the L2 address, IP address and the network prefix. The Fast Handover
protocol refers to this as the (AP-ID, AR-Info) tuple. The solicited
information, which resembles performing inverse IPv6 Neighbor Discovery but
for an off-link address, is restricted to subnet configuration information
necessary to pre-configure the wireless node for the neighboring subnet
(i.e., the access router L2 and IP address and, for IPv6, subnet prefix). No
other characteristics of the neighborhood subnets are defined since subnet
information is sufficient for route update purposes.
The difference between FMIP/LLMIP and CARD can be summarized as follows. The
fast handover protocols are primarily interested in new subnet information
for initiating route updates for optimizing handover delay and packet loss.
CARD, on the other hand, enables a wireless node to gather attributes
associated with the target subnets so that a suitable target access router
can be selected for handover. Once such an access router is selected, the
fast handover protocols actually effect the routing changes.
The purpose of NED is to define unified packet formats for use by protocols
defined in [FMIP], [LLMP], and [CARD] and make the functions independent of
transport protocol, so neighborhood discovery can be done over IP transport
of both versions. In addition, NED has been designed to satisfy the
requirements of 802.21 [802.21] for transport-independent network discovery.
3.0 Potential Uses
This section describes three potential uses for NED.
3.1 IEEE 802.21
As a functional and architectural requirement for its Media Independent
Handover (MIH) service, IEEE 802.21 is defining an Information Service in
Section 4.3 of [802.21]. The purpose of this Information Service is to
assist a node in obtaining information such as link access and utilization,
link quality, cost, security mechanisms, provider information and other
information elements relevant for a selecting an appropriate network
interface and for mobility. An important requirement for this information
service is access independence, so that the service can be provided on
multiple networks, including IEEE 802.11, 802.15, 802.16 as well as cellular
networks. Such an access-independent service can be best served by messages
with generic binary formats for supporting individual information element
queries. For example, a simple Request and Reply message sequence with a
generic option format can be used to query the link quality parameter on any
network that supports the IEEE 802.21 MIH service. NED can provide the
substrate upon which the types of information defined in [802.21] is
specified.
3.2 IP Mobility Handover Support
One of the original motivations behind CARD was to support decision making
on the mobile node for selection of a handover target router for FMIPv6 and
LLMIPv4. NED provides a more general link information format, having some
backward compatibility with CARD.
Kempf & Koodli Expires December 2005 [Page 5]
Internet Draft NED June, 2005
3.3 Information Distribution on Link Characteristics
The other motivation behind CARD was to support distribution of information
between access routers, so an access router can advertise information about
surrounding subnets. The same information elements used between the access
router and mobile node are also used between access routers for this
purpose. The NED information elements can serve the same purpose. CARD
defines SCTP as the transport protocol between access routers, the same
protocol can be used for NED.
4.0 Neighborhood Discovery Protocol Overview
Because NED can be used over multiple transports, the protocol only
defines the wire format of requests for neighborhood information and
responses containing the neighborhood information, just as in EAP
[RFC3748]. Other protocol considerations, such as the details of
message transmission, are determined by the respective transport. For a
complete protocol, this specification MUST be paired with an
appropriate transport specification describing how NED is used over the
transport, including such issues as retransmission and fragmentation.
NED information elements are defined as attribute/value pairs (AVPs).
NED AVPs are defined defined for particular applications, such as
router discovery or link identification. The AVPs are identified by an
attribute type and are registered with the Internet Assigned Numbers
Authority in the Seamoby CARD Parameters AVP Type Registry. The
wireless access technology identifiers are defined there as well, in
the Layer 2 Access Technology Identifier Registry. The Seamoby CARD
Parameters registries can be found in [REG]. Section 7.0 describes how
to standardize a new AVP type.
In typical usage, a NED-capable node solicits a peer for information on
its neighborhood by sending a Neighborhood Discovery Request (NED-RQST)
message containing a list of Network Information Request Options. Each
option contains a list of Layer 2 access point addresses and a list of
AVP type codes. The elements in the Layer 2 access point identifier
list consist of the following two objects:
1) A wireless access technology identifier indicating the type of
wireless link technology on the interface where the access point
identifiers were observed,
2) A list of Layer 2 addresses for wireless access points in the
identified network discovered during passive or during active
scanning.
If the list of AVP type codes is empty, the soliciting node is requesting
that all available information on the network associated with the access
points should be provided.
The peer replies with a Neighborhood Discovery Reply (NED-RPLY)
containing a list of Network Information Reply Options. Each option
contains a list of Layer 2 access point addresses having the same
format, but possibly different content, as the NED-RQST list, and a
list of AVP values with the requested information for the network with
Kempf & Koodli Expires December 2005 [Page 6]
Internet Draft NED June, 2005
which the access points are associated. If the information is not
available, the AVP list is empty and a status bit in the option header
indicates the reason.
A wireless node, an access point, a router, or a switch may solicit all
information available to a particular peer in order to provide a
database of such information. The database can be used for handover,
initial access decision making, or in the case of support nodes such as
routers, access points, and switches, to support wireless nodes on the
link. Additionally, a node may push information to a peer unsolicited
if a change in the characteristics of its network occurs, and if
unsolicited transfer is supported by the transport. NED itself does not
provide the details about how these information exchanges are
conducted, that is up to the transport protocol specification.
5.0 Protocol Messages
This section describes the wire format of NED protocol messages.
5.1 Protocol Header
The basic protocol format is modeled after the Extensible Authentication
Protocol [RFC3748]. The following describes the protocol header.
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 |Vers.| Rsrved.| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type:
0 Neighborhood Discovery Request (NED-RQST)
1 Neighborhood Discovery Reply (NED-RPLY)
Since NED only defines codes 0 and 1, all other packets
MUST be discarded by peers.
Vers.:
A three bit version number indicating the version of the
protocol. For this document, the version number is 0.
Rsrvd.:
Set to zero on transmission and ignored on reception.
Length:
Kempf & Koodli Expires December 2005 [Page 7]
Internet Draft NED June, 2005
Two octet length of the NED message, including header, in
octets.
Options:
A list of Option objects. For a NED-RQST, the list MUST
consist only of Network Information Request Options. For
NED-RPLY, the list MUST consist only of Network Information
Reply Options.
5.2 Network Information Request Option
The Network Information Request Option can only appear in the NED-RQST
message. It has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Reserved | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Layer 2 Access Point Identifier List Field (variable) |
+ +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Attribute Type Code List Field (variable) |
+ +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Option Type:
TBD1 (assigned by IANA)
Reserved:
Set to zero on transmission and ignored on reception.
Option Length:
Two octet length of the option, including header, in
octets.
Layer 2 Access Point Identifier List Field:
A variable length field containing a list of Layer 2 access
point address identifiers in the network for which
Kempf & Koodli Expires December 2005 [Page 8]
Internet Draft NED June, 2005
information is desired. The format of the list is described
in Section 5.4.
Attribute Type Code List Field:
A variable length field containing a list of attribute type
codes for which information is desired. The format of the
list is described in Section 5.5. If the requestor wants
all information associated with the network, the list is
empty.
5.3 Network Information Reply Option
The Network Information Reply Option can only appear in the NED-REPLY
message. It has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Status | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Layer 2 Access Point Identifier List Field (variable) |
+ +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| AVP List Field (variable) |
+ +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Option Type:
TBD2 (assigned by IANA)
Reserved:
Status code indicating the status of the request. Defined
values are given in Section 5.7.
Option Length:
Two octet length of the option, including header, in
octets.
Layer 2 Access Point Identifier List Field:
Kempf & Koodli Expires December 2005 [Page 9]
Internet Draft NED June, 2005
A variable length field containing a list of Layer 2 access
point address identifiers in the network for which
information is desired. The format of the list is described
in Section 5.4.
AVP List Field:
A variable length field containing a list of
attribute/value pairs containing information for the
network in which the access points are located. The format
of the list is described in Section 5.6. If list is empty,
no information is available on the network in which the
access points are located.
5.4 Layer 2 Access Point Identifier List Field
The size of the Layer 2 Access Point Identifier List Field is variable,
depending on the number of Layer 2 access point address identifiers in the
list, and on the length of the individual identifiers. The size of the
individual Layer 2 access point address identifiers depends on the Layer 2
technology. The Layer 2 Access Point Identifier List Field has the following
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length | Layer 2 Access Technology ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Layer 2 Access Point ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Layer 2 Access Point ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Field Length:
Two octet length of the field, including header, in octets.
Layer 2 Access Technology ID:
Two octet identifier for the Layer 2 access technology
utilized by the access points whose address identifiers are
in the list. The access technology identifier is taken from
the Layer 2 Technology Identifier Registry in the Seamoby
IANA registry at [REG].
Layer 2 Access Point ID:
A variable length field containing the Layer 2 access point
address identifier. The length of the identifier depends on
Kempf & Koodli Expires December 2005 [Page 10]
Internet Draft NED June, 2005
the Layer 2 access technology type, specified by the Layer
2 Access Technology ID.
5.5 Attribute Type Code List Field
The size of the Attribute Type Code List Field is variable, depending on the
number of two octet attribute type codes included in the list. The Attribute
Type Code List Field has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length | Attribute Type Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type Code | Attribute Type Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Field Length:
Two octet length of the field, including header, in octets.
Attribute Type Code:
Two octet identifier attribute type code. The attribute
type code is taken from the AVP Type Registry in the
Seamoby IANA registry at [REG].
5.6 AVP List Field
The size of the AVP List Field is variable, depending on the number of AVPs
in the list, and on the length of the individual AVP objects. The size of
the individual AVP objects depends on the attribute type. The AVP List Field
has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Object...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Object...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Field Length:
Kempf & Koodli Expires December 2005 [Page 11]
Internet Draft NED June, 2005
Two octet length of the field, including header, in octets.
Reserved:
Set to zero on transmission and ignored on reception.
AVP object:
A variable length field containing the AVP object. Section
5.6.1 describes the AVP object format.
5.6.1 AVP Object
The AVP Object is of variable length, depending on the value data. The AVP
Object has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Fields:
AVP Code:
Two octet AVP type code, from [REG].
AVP Length:
Two octet length of the AVP, including header, in octets.
Value Data:
A variable length field containing the AVP data. AVPs are
defined and registered with IANA as described in [RFC4065].
5.7 Status Code Values
This specification defines the following status code values for NED-REPLY:
Code Meaning
---- -------
0 Request was successfully completed, AVPs follow
1 Request denied for administrative reasons
2 Request was unsuccessful because no information is
available on the requested access point identifiers.
Kempf & Koodli Expires December 2005 [Page 12]
Internet Draft NED June, 2005
3 Request has been partially completed, AVPs follow
6.0 Security Considerations
NED depends on the transport to provide security for the NED
transaction. A transport definition for NED MUST provide data origin
authentication and replay protection on the NED-REPLY to ensure that
the source of the provided information is a trusted node. The transport
definition MUST provide data origin authentication and replay
protection on the NED-RQST and confidentiality protection on both the
NED-RPLY and NED-RQST if the information is being distributed between
network nodes that are acting as authoritative sources of network
neighborhood information for other nodes, such as between routers,
switches, and access points.
7.0 IANA Considerations
NED Layer 2 Access Technology identifiers are defined in the IANA
Seamoby Layer 2 Access Technology Identifier registry [REG].
NED AVPs have the same format as CARD Capability AVPs and are defined
in the IANA Seamboy CARD AVP Type Registry [REG].
New Layer 2 Access Technology identifiers and AVPs are registered with
IANA as described in [RFC4065].
NED Option types require the definition of a new IANA registry called
"NED Options Registry", and the assignment of two option numbers for
Network Information Request Option and Network Information Reply
Option, TBD1 and TBD2 above. Future NED options can be added through
the method of IETF Standards Action, as defined in [RFC2434].
NED status codes require the definition of a new IANA registry called
"NED Status Codes". Future NED status codes can be added through the
method of IETF Standards Action, as defined in [RFC2534].
8.0 Normative References
[RFC3773] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
3773, June 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility
Protocol IANA Allocations", RFC 4065, May, 2005.
[RFC2434] Narten, T., and Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October, 1998.
Kempf & Koodli Expires December 2005 [Page 13]
Internet Draft NED June, 2005
9.0 Informative References
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
Levkowetz, H., "Extensible Authentication Protocol (EAP)",
RFC 3748, June, 2004.
[EAPSEL] Aboba, B., and Arkko, J., "Network Discovery and Selection
Problem", Internet Draft, work in progress.
[MIP4] Perkins, C., editor, "Mobility Support for IPv4," RFC 3344,
August, 2002.
[MIP6] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
IPv6," RFC 3775, June, 2004
[SEND] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure
Neighbor Discovery (SEND)", RFC 3971, March, 2005.
[CARD] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and Shim, E.,
"Candidate Access Router Discovery", Internet Draft, approved for
publication October 2004.
[FMIP] Koodli, R., editor, "Fast Handovers for Mobile IPv6", Internet
Draft, work in progress.
[LLMP] El Malki, K., "Low Latency Handoffs in Mobile IPv4", Internet
Draft, work in progress.
[802.21] Gupta, V., (Editor), "IEEE P802.21 Media Independent Handover
Service Draft Technical Requirements", IEEE, September 2004.
[REG] http://www.iana.org/assignments/card-parameters
10.0 Author Information
James Kempf Phone: +1 408 451 4711
DoCoMo Labs USA Email: kempf@docomolabs-usa.com
181 Metro Drive
Suite 300
San Jose, CA
95110
USA
Rajeev Koodli Phone: +1 650 625 2359
Nokia Research Center Fax: +1 650 625 2502
313 Fairchild Drive Email: Rajeev.Koodli@nokia.com
Mountain View, CA
94043
USA
11.0 IPR Statements
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
Kempf & Koodli Expires December 2005 [Page 14]
Internet Draft NED June, 2005
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.
13. 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.
14. Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as set
forth therein, the authors retain all their rights.
Kempf & Koodli Expires December 2005 [Page 15]
