Internet Draft Hee Young Jung Internet Engineering Task Force ETRI Expires February 2004 Seok Joo Koh August 2003 ETRI Dae Young Kim CNU Address Pool based Stateful NCoA Configuration for FMIPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are 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 a "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 The DAD procedure for NCoA validation is a burden for achieving the fast MIPv6 handover. The existing stateless and DHCPv6-based stateful NCoA configuration schemes are all concerned with the DAD process at NAR. This document describes an NCoA address pool based stateful NCoA configuration for MIPv6 fast handover (FMIPv6). To reduce the DAD handling time during the handover, the NCoA pools are established at NAR (in the reactive stateful scheme) or PAR (in the proactive stateful scheme). An NCoA pool maintains a list of NCoAs already confirmed by the corresponding NAR. In response to a handover request, the NAR or PAR will allocate a confirmed NCoA to the MN. By the address pool based stateful NCoA configuration, the handover latency can be significantly reduced, and a tunneling for handover can be extended to an NCoA address, instead of NAR. Jung, Koh, Kim [Page 1] INTERNET DRAFT Stateful FMIPv6 August 2003 1. Introduction and Motivations One of the primary goals of fast handover for MIPv6 [1, 2] is to minimize the handover latency required for handover. It is noted that the handover latency could largely be impacted by the NCoA configuration mechanism involved. Generally, the NCoA configuration schemes can be classified into: o Stateless NCoA configuration o Stateful NCoA configuration Stateless NCoA configuration scheme [3] basically requires the DAD handling at the NAR. The use of DAD to verify the uniqueness of an IPv6 address configured through stateless auto-configuration may add significant delays to a MIPv6 handover, and hence a large handover latency. Even if the duplication probability of an interface ID on the same subnet is very low, it cannot be ignored. It is noted that a couple of optimization schemes have recently been proposed so as to deal with the DAD handling issues, as seen in 'optimistic DAD' [4] and 'advance DAD' [5]. However, it still needs further enhancement works for effectively applying stateless address configuration to fast handover for MIPv6. FMIPv6 also considers a stateful NCoA configuration based on a special server, typically DHCPv6 [6]. In response to a request from PAR via the HI message, the NAR returns an NCoA via the HACK message by referring to a DHCPv6 server attached. The DHCPv6 based stateful NCoA configuration scheme still requires the DAD handling or NCoA validation procedures at NAR. Furthermore, the time for NAR to perform the DHCPv6 protocol may not be negligible during the overall handover period. In this document, we propose to use NCoA pools for stateful NCoA configuration at ARs. For fast handover support, each AR is required to manage the NCoA pools to ensure that each NCoA contained in the pool is validated and confirmed by the corresponding NAR, so that it could be immediately available in response to the NCoA request from MN (or PAR). The address pool based stateful NCoA configuration is free from the DAD handling burden, compared to the existing stateless and DHCPv6 based stateful NCoA configuration schemes. Accordingly, it is expected that the stateful NCoA configuration method could reduce the handover latency concerned with the DAD handling. Jung, Koh, Kim [Page 2] INTERNET DRAFT Stateful FMIPv6 August 2003 In addition to the reduced handover latency, the address pool based NCoA configuration scheme gives another benefit to FMIPv6. That is, the PAR could establish a bi-directional tunnel to NAR with NCoA address, instead of NAR address, since the NCoA was already proved to be valid in the NAR region. 2. Terminology 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. This document uses the terms defined in MIPv6 [1] and FMIPv6 [2]. 3. Framework of Address Pool based Stateful NCoA Configuration 3.1 NCoA Pools for Fast Handover Support An 'NCoA pool' is an address pool that maintains a list of NCoAs to be used for supporting MIPv6 handover. An AR keeps and manages an NCoA address pool for each neighboring ARs (i.e., for each interface). For handover support, each NCoA in the pool will have been validated for use by the corresponding NAR. Depending on where the NCoA pool is located at, the address pool based configuration schemes are divided into the following two cases: o Reactive stateful NCoA configuration (NAR-based) The NCoA pool is located at NAR. On a request of NCoA from MN (or PAR) via the HI message, the NAR assigns a confirmed NCoA to the requesting MN from the NCoA pool via the HACK message. o Proactive stateful NCoA configuration (PAR-based) The NCoA pool is located at PAR, and updated by an out-of-band signaling between PAR and NAR. In response to the handover request from MN via RtSolPr, the PAR immediately assigns a confirmed NCoA to the requesting MN from the NCoA pool via the PrRtAdv message. In this scheme, the HI/HACK exchange is done only for tunnel establishment, without NCoA allocation and confirmation. In any case, the NAR (reactive) or PAR (proactive) will respond with a confirmed NCoA to the request from the MN. Jung, Koh, Kim [Page 3] INTERNET DRAFT Stateful FMIPv6 August 2003 3.2 Reactive Stateful NCoA Configuration In the reactive stateful NCoA configuration scheme, each AR (NAR) SHOULD keep and maintain a list of NCoAs in the NCoA pool all the time. Each of the NCoAs in the pool SHOULD have been validated and confirmed by NAR. When one of its neighboring PARs asks for handover via an HI message, it will immediately respond with an NCoA to the PAR via the responding HACK message, as shown in Figure 1. Note that the NAR will respond to the NCoA request from each of its neighboring PARs. In the figure, one NAR and its two neighboring PARs are shown for an example. +---------+ |NCoA Pool| | for NAR | +---------+ | | +------+ HI +-------+ HI +------+ | |-------------->| |<--------------| | | PAR1 | | NAR | | PAR2 | | |<--------------| |-------------->| | +------+ HACK +-------+ HACK +------+ Figure 1. Network Model for Reactive NCoA Configuration Figure 2 shows a timing diagram for fast handover using the reactive stateful NCoA configuration. When an MN triggers the handover by RtSolPr or an L2 trigger, the PAR requests an NCoA to NAR via the HI message, and the NAR then delivers a confirmed NCoA to PAR. In turn, the PAR allocates it to the MN via the PrRtAdv message. MN PAR NAR | | | |------RtSolPr------->| | | |--------HI--------->| | |<------HACK---------|~~> w/o DAD, |<-----PrRtAdv--------| | tunnel to NCoA | | | |------F-BU---------->| | | <--F-BACK--|--F-BACK--> | | | | Figure 2. Reactive NCoA Configuration in FMIPv6 Jung, Koh, Kim [Page 4] INTERNET DRAFT Stateful FMIPv6 August 2003 The term 'Reactive' is used in the viewpoint that an NCoA is statefully allocated by NAR when the PAR requests it. The reactive stateful scheme is different from the existing DHCPv6 based stateful scheme since the NAR is always maintaining a set of NCoAs available and confirmed, so that a further DAD handling is not necessary during the handover process. 3.3 Proactive Stateful NCoA Configuration In the proactive stateful NCoA configuration scheme, each AR (PAR) SHOULD keep 'NCoA Pools' for its respective neighboring ARs (i.e., prospective NARs), as shown in Figure 3. Note that the PAR SHOULD manage an NCoA pool for each of the neighboring NARs. In the figure, for example, only two NCoA Pools are shown for NAR1 and NAR2, respectively. +---------+ +---------+ |NCoA Pool| |NCoA Pool| |for NAR1 |--+ +--|for NAR2 | +---------+ | | +---------+ | | +------+ +-------+ +------+ | | Signaling | | Signaling | | | NAR1 |<=============>| PAR |<=============>| NAR2 | | | | | | | +------+ +-------+ +------+ Figure 3. Network Model for Proactive NCoA Configuration The term 'Proactive' is employed in the viewpoint that an NCoA is allocated by PAR without further requesting to NAR. When receiving a PrSolPr from MN, the PAR obtains an NCoA (confirmed) from the NCoA pool. The PAR then responds with a confirmed NCoA (via PrRtAdv) to MN. Note in the proactive configuration scheme that the HI/HACK exchange is done only for tunnel establishment, not for the NCoA configuration and confirmation at NAR. Accordingly, the time required for processing the HI and HACK could be more reduced, compared to the Reactive configuration scheme. Figure 2 illustrates the handover timing diagram by Proactive scheme. Jung, Koh, Kim [Page 5] INTERNET DRAFT Stateful FMIPv6 August 2003 MN PAR NAR | | Out-of-Band | | | Signaling | | |<==================>| |------RtSolPr------->| | |<-----PrRtAdv--------|--------HI--------->| | |<------HACK---------|~~> w/o DAD, |-------FBU---------->| | tunnel to NCoA | <---FBACK--|--FBACK---> | | | | Figure 2. Proactive NCoA Configuration in FMIPv6 For supporting the proactive NCoA configuration, the PAR needs to generate NCoAs and manage them to ensure that the respective NCoAs are unique in the NAR. In particular, the NCoA generation MAY be implemented by using one of the followings: (1) Generation of NCoAs by PAR may be done by using network prefix of the corresponding NAR as the network prefix portion of an NCoA. The remaining interface ID portion may be filled with a random number or by using a pre-specified rule exploiting the MN's link layer identifier. (2) Instead of PAR, the NAR may randomly generate a list of NCoAs available and then gratuitously deliver them to PAR via an out- of-band signaling, as described below. (3) As an alternative to NCoA generation randomly, the PAR or NAR MAY use a specific scheme for generating a globally unique NCoA for an MN, without a need to confirmation by NAR. Such an NCoA generation scheme will depend on the addressing scheme of the underlying link layer, such as Ethernet-based or Cellular-based. More detailed scheme is for further study. Another key element for realizing the proactive stateful NCoA configuration is 'signaling' for NCoA pool management between PAR and NAR. Such signaling will intrinsically be done out-of-band because the signaling mechanisms are performed independently of the FMIPv6 handover procedures, and thus the time required for the signaling is excluded from the overall handover latency. The main objective of the signaling is to ensure that the NCoA address pool always maintains a list of NCoAs available and confirmed by the corresponding NAR. To do this, the PAR should request the NCoA confirmation to the NAR and also update the NCoA pool based on the response from the NAR. Jung, Koh, Kim [Page 6] INTERNET DRAFT Stateful FMIPv6 August 2003 4. Impacts on FMIPv6 Basically, the address pool based stateful NCoA configuration schemes conform to the FMIPv6 handover [2]. In this section, the FMIPv6 procedures are described when the reactive and proactive stateful NCoA configuration apply. 4.1 FMIPv6 in the reactive NCoA Configuration The handover procedures based on the reactive stateful NCoA configuration is basically identical to those for the DHCPv6 based stateful configuration scheme, as described in [2], except that the NAR refers to its NCoA pool, not the DHCPv6 server. In response to RtSolPr message (or by an L2 trigger in the network initiated case), the PAR requests an NCoA to the corresponding NAR via the HI message. In response, the NAR takes an NCoA out of its NCoA pool and deliver it to the PAR via the HACK message. Note that the allocated NCoA has already been confirmed by NAR, as described so far in this document. Then the PAR sends the PrRtAdv message that MUST include 'New CoA Option', as specified in 6.1.2 of [2]. 4.2 FMIPv6 in the proactive NCoA Configuration In response to RtSolPr message (or by an L2 trigger in the network initiated case), the PAR allocates an NCoA to the MN out of the address pool for the corresponding NAR. Note that the allocated NCoA has already been confirmed by NAR, as described so far in this document. Then the PAR sends the PrRtAdv message that MUST include 'New CoA Option', as specified in 6.1.2 of [2]. As soon as the PAR transmits PrRtAdv to MN, it may also sends an HI message to the NAR, as described in 5.2 of FMIPv6 [2]. Note in the proactive scheme that the HI message is used 'only' for establishing a bi-directional tunnel, since the NCoA was already confirmed. Note in the HI message (see 6.2.1 of [2]) that: o 'S' flag MUST NOT be set, although it is a stateful configuration scheme, since the S flag set requests an NCoA to NAR. The S flag is set only in the 'Reactive' stateful scheme. o 'New CoA Option' SHOULD be present, although the S bit is zero, so as to indicate that the MN wishes to use the NCoA in the NAR. Jung, Koh, Kim [Page 7] INTERNET DRAFT Stateful FMIPv6 August 2003 In response to the HI message, the NAR sets up a host route for the MN's PCoA and responds with a Handover Acknowledge (HACK) message. Note in the HACK message (see 6.2.2 of [2]) that: o ICMP Code SHOULD be set to 0, if not an error case (128 ~ 131). That is, the codes of 1 ~ 4 are not used. o 'New CoA Option' SHOULD be present, although the S bit is zero, so as to indicate that the MN should use the NCoA in the NAR. After the HI/HACK exchange, the MN can send a Fast Binding Update (FBU) to PAR so as to request that the packets arriving at the PAR can be tunneled to the NAR. In the stateful configuration scheme, the FBACK may not be used because the MN already knows the availability of NCoA on NAR. In this case, the 'A' flag of FBU will not be set. Even when the FBACK is used, the PAR SHOULD promptly send the FBACK in response to FBU. Accordingly, it is likely that the FBACK is sent only to PAR, not to NAR. Use of the FNA and NAACK options is identical to that of FMIPv6. Similar to the use of FBACK message, the NAACK option may not be used. 5. Further Considerations The following further issues may need to be considered in the future: o Specific schemes to generate the candidate NCoAs at PAR or NAR. o Signaling mechanisms for confirming and update the candidate NCoAs in the proactive stateful scheme. 6. References [1] D. Johnson, et al., "Mobility Support in IPv6", draft-ietf-mobileip- ipv6-24, June 2003. [2] R. Koodli, et al., "Fast Handovers for Mobile IPv6", draft-ietf- mobileip-fast-mipv6-06, March 2003. [3] S. Thomson, et al., "IPv6 Stateless Address Autoconfigurationö, RFC 2462, December 1998. [4] N. Moore, "Optimistic Duplicate Address Detection", draft-moore-ipv6- optimistic-dad-02, February 2003. Jung, Koh, Kim [Page 8] INTERNET DRAFT Proactive FMIPv6 August 2003 [5] Y. Han, J. Choi, and S. Park, "Advance Duplicate Address Detection", draft-han-mobileip-adad-01, July 2003. [6] R. Droms (Ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 7. Author's Addresses Hee Young Jung hyjung@etri.re.kr Protocol Engineering Center, ETRI Seok Joo Koh sjkoh@etri.re.kr Protocol Engineering Center, ETRI Dae Young Kim dykim@cnu.ac.kr Chungnam National University, KOREA Jung, Koh [Page 9]