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]