DRAFT Keiichi Shima Internet Initiative Japan Inc. December 7, 2001 KAME Mobile IPv6 Implementation notes Abstract The KAME Project is now developping Mobile IPv6 stack on its IPv6 stack. We will describe our implementation design and some comments about the spec. Status of this Memo This document is a supplemental reference for those implementing MIP6. draft-keiichi-mobileip-kame-implementation-00.txt [Page 1] DRAFT KAME Mobile IPv6 Implementation Dec. 7, 2001 Table of Contents 1. Overview ........................................................ 3 2. KAME/MIP6 implementation note ................................... 3 2.1. Subnet in KAME/MIP6 ........................................ 3 2.2. CoA selection in KAME/MIP6 ................................. 4 2.2.1. Comment about the spec .............................. 4 2.3. Movement detaction in KAME/MIP6 ............................ 5 2.4. One more note about CoA selection .......................... 5 2.5. Multiple homelinks ......................................... 6 2.6. Router Identifier Problem .................................. 6 2.6.1. Comment about the spec .............................. 6 2.7. The wrong source address in the ICMP error payload ......... 6 2.7.1. Comments ............................................ 7 2.8. Security mechanism is not implemented yet .................. 7 3. References ...................................................... 7 4. Current status .................................................. 7 5. Author's Address ................................................ 9 draft-keiichi-mobileip-kame-implementation-00.txt [Page 2] DRAFT KAME Mobile IPv6 Implementation Dec. 7, 2001 1. Overview KAME/MIP6 is based on the three implementations (Ericsson, NEC, Keio Univ.) those have been built on the KAME IPv6 protocol stack before. We are trying to utilize the merits of those implementations and provide one concrete MIP6 stack for the KAME IPv6 stack. Since the code is under developing, the information written in this document may be outdated, but I think this is still useful to understand our implementation. The KAME/MIP6 supports CN, HA and MN functions. The base specification is the current one. At this point, the specification is draft-ietf-mobileip-ipv6-15.txt. 2. KAME/MIP6 implementation note 2.1. Subnet in KAME/MIP6 MIP6 is designed for the node that is moving from one subnet to another subnet without closing existing connections. When the node moves from one subnet to other subnet, we think the node has moved. MIP6 spec doesn't define the notation of subnet. KAME/MIP6 defines the word subnet as 'the group of prefixes and routers those have some relationships with each other'. See the following example. Router R1 announcing Prefix P1, Prefix P2 Router R2 announcing Prefix P3, Prefix P4 Router R3 announcing Prefix P1, Prefix P5 Router R4 announcing Prefix P4, Prefix P6 Router R5 announcing Prefix P7 In this case, we have 5 routers (R1...R5) and 7 prefixes (P1...P7). By our definition of subnet, we can group them into 3 subnets. Subnet S1 (Router R1, R3) (Prefix P1, P2, P4) Subnet S2 (Router R2, R4) (Prefix P3, P4, P6) Subnet S3 (Router R5) (Prefix P7) Router R1 and R3 are in the same subnet because those routers share the prefix P1. Similarly, Router R2 and R4 are the same subnet. Router R5 is only router in the subnet S3 because it doesn't share draft-keiichi-mobileip-kame-implementation-00.txt [Page 3] DRAFT KAME Mobile IPv6 Implementation Dec. 7, 2001 any information with other router. KAME/MIP6 treats these 3 subnet as different ones, even if they are physically on the same wire. 2.2. CoA selection in KAME/MIP6 The KAME/MIP6 stack re-selects the CoA when the states of prefixes have changed. The KAME IPv6 stack maintain all the received prefixes. The point is that the KAME stack has one more additional state information of the prefix than the specification defines. The stateless address auto-configuration specification defines some states of IPv6 addresses. In this paper, we focus two states, one is PREFERRED and the other is DEPRECATED. These states are derived from the prefix states. If the prefix has the preferred lifetime left, the address derived from the prefix is also PREFERRED. If the prefix has only the valid lifetime left and the preferred lifetime expired, the address is DEPRECATED. In addition to those states, the KAME IPv6 stack has a DETACHED address state. If the prefix has the valid lifetime left but the advertising router of the prefix seems unreachable, the prefix is marked as detached. The address derived from the detached prefix is also marked as DETACHED. Following are the algorithm of KAME/MIP6 CoA selection. 1. find addresses those are not ANYCAST, DUPLICATED, DEPRECATED and DETACHED. 2. if the previous CoA is one of addresses found during the procedure 1, continue using the same address as the CoA. 3. if the previous CoA is not found, select one address from addresses found during the procedure 1. Current implementation pick the last found address as a new CoA. We can introduce some policy based address selection mechanism in the selection procedure. For example, we may want to mark the Ethernet interfaces as perferrable than the cellular interfaces. This CoA selection algorithm is the key of the movement detection algorithm of the KAME/MIP6. The movement detection is described in the next section. 2.2.1. Comment about the spec We have no mechanism to invalidate the old prefix. 'Old' means, it has preferred lifetime left but, no advertising router on the current subnet. This happens when we change the network. We have no way to determine if we can use the old (in KAME sense, detached) address. draft-keiichi-mobileip-kame-implementation-00.txt [Page 4] DRAFT KAME Mobile IPv6 Implementation Dec. 7, 2001 Should the autoconf spec note about this? 2.3. Movement detaction in KAME/MIP6 While many implementations check advertised prefixes and default router change to detect the node movement, KAME/MIP6 only checks the change of its CoA. As already described, KAME/MIP6 CoA re-selection is done whenever the states of prefixes change. Therefore, the change of the CoA in our implementation means the old prefix of the old CoA is no longer usable. It is not important whether the node moves from one wire to another wire. The point is the node always selects its CoA based on the states of the current usable prefixes and routers those are advertising prefixes. Once the CoA has changed, we must update binding regardless of moving from one real wire to another. When KAME/MIP6 detects movement (this means that KAME/MIP6 detects CoA change), KAME/MIP6 start movement processing. For example, sending binding updates to each destination node of binding update list. 2.4. One more note about CoA selection Our algorithm may detect wrong location in the following case. ----+-------- ----+------- | | +-+--+ +-+--+ | R1 | | R2 | +-+--+ Prefix P1 +-+--+ Prefix P2 | | ----+---------------+---------------+---- home wire | +----+ home prefix == P1 | MN | +----+ There are two routers (R1, R2) in the home wire. Router R1 announces Prefix P1 and R2 announces P2. By definition of our subnet, there are two subnets on the wire. Subnet S1 (Router R1) (Prefix P1) Subnet S2 (Router R2) (Prefix P2) Under this condition, if we specify only one prefix as a home prefix, we can't determine whether we are home or not. In this network, both draft-keiichi-mobileip-kame-implementation-00.txt [Page 5] DRAFT KAME Mobile IPv6 Implementation Dec. 7, 2001 P1 and P2 are valid. We can use both addresses derived from each prefix. Now, assume we select P1 as a home prefix. If we select CoA derived from P2, we determine that we are on the foreign network. But in fact, we are home too. MN will start configuring addresses and get two addresses. One is from P1 and the other is from P2. Next, MN sends a binding update to make a home registration but it fails because HA fails DAD for the MN home address. In this case, MN should determine that it is home. This problem can be easily avoided by preferring the home address in selecting a new CoA. (Not implemented yet.) (Current implementation have bugs in handing this situation, so, this doesn't work with such a network described above.) 2.5. Multiple homelinks The KAME/MIP6 try to support multiple homelinks. We can specify both office and home network as a home link. We can use the best address (if we are office, office home address, and vice versa). 2.6. Router Identifier Problem As many folks have said already, our implementation also have a router identifier problem. If different two routers have same link- local address, we think those two routers are the same router. This problem can be avoided by using router global address. But, since the global address is included in the prefix infomation option of the router advertisement, we must process the prefix information option twice. First time for finding a global address, second time for grouping received prefixes into subnet groups (and also, ordinally prefix information option processing). 2.6.1. Comment about the spec Do we need another identifier other than the link-local address? Or this is only the operational problem? 2.7. The wrong source address in the ICMP error payload In our implementation, the home address and the CoA is exchanged in the destination options header processing routine. If we encounter draft-keiichi-mobileip-kame-implementation-00.txt [Page 6] DRAFT KAME Mobile IPv6 Implementation Dec. 7, 2001 some errors after this point, it produces the ICMP error packet with a payload that include the original IPv6 packet with a wrong (excnanged) source address. To avoid this problem, we consider two different mechanisms. One is to recover a correct source address at all the points the process are needed. The other is not to exchange the home address and the CoA in the destination options header processing and remain the CoA in a IPv6 source address field. We implemented both mechanisms and decided to adopt the former. In the former mechanism, the point to recover the original source address is only the function which generates ICMP error packet. Other parts of the code seems to have no need to restore the source address. While, the latter mechanism requires tens to a hundred code fixes those refer the IPv6 source address field. 2.7.1. Comments We select the former mechanism because it require only a small fix of the existing code. But we should reconsider if the former mechanism is better than the latter mechanism later. It is natural to keep the IPv6 packet not modified. If we meet some other situations like ICMP6 error in the future, we must make a code that recover the original source address again as we have done in the current icmp6error routine. Is it really ad-hoc isn't it? 2.8. Security mechanism is not implemented yet We plan to implement some weak authentication mechanisms. Currently we are investigating which one is the best. 3. References [MIP6] David B. Johnson, Charles Perkins, Mobility Support in IPv6, draft- ietf-mobileip-ipv6-15.txt, Nov 2001 [RFC2462] S. Thomson, T. Narten, IPv6 Stateless Address Autoconfiguration, RFC2462, Dec 1998 4. Current status Followings are the todo list and the current status for each func- tions (MN, HA, CN). You can always get the latest information from the KAME Project (http://www.kame.net/). draft-keiichi-mobileip-kame-implementation-00.txt [Page 7] DRAFT KAME Mobile IPv6 Implementation Dec. 7, 2001 - todo - merge nd_prefix/nd_defrouter structure and mip6_prefix/mip6_ha structure. merge home address configuration and stateless auto- configuration. current our implementation defines special prefix and home agent structures for MIP6 code. These structures are essentially iden- tical to nd_prfix and nd_defrouter structures. should merge them. - define the behavior of the socket API for home addresses. we do not implement any MIP6 related socket APIs yet. - security mechanism. There are many candidates now to secure MIP6 processing. we are now comparing them. - mobile prefix advertisement. - complete dynamic home agent discovery. (implement user-land dae- mon?) - rate limit (many places). - homeagent info handling. - ICMP against tunneled packet handling. - registration to the old AR. - path mtu discovery when triangle routing. - some timeout routines. - other OSes support. - draft-13/draft-15 (or newer) full support. - may be others. - MN part implemented functions - movement detection by the CoA change. - binding update/home registration. draft-keiichi-mobileip-kame-implementation-00.txt [Page 8] DRAFT KAME Mobile IPv6 Implementation Dec. 7, 2001 - dynamic home agent discovery. - NA when returning to home. - CN part implemented functions - receiving binding update. - insertion of a routing header. - sending binding requests. - HA part implemented functions - home registration. - encapsulate packets destined to MNs. - dynamic home agent discovery (partial). - dad for the MNs. 5. Author's Address Keiichi Shima Internet Initiative Japan Inc. Edobori Center Bldg. 19F 2-1-1 Edobori, Nishi-ku, Osaka 550-0002, Japan Email: keiichi@iij.ad.jp draft-keiichi-mobileip-kame-implementation-00.txt [Page 9]