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]