idnits 2.17.1 draft-teraoka-ipng-lin6-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 176 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 June 2003) is 7610 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2461' is mentioned on line 795, but not defined ** Obsolete undefined reference: RFC 2461 (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEICE01' -- Possible downref: Non-RFC (?) normative reference: ref. 'WPMC01' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-14 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2374 (Obsoleted by RFC 3587) -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Fumio Teraoka 3 INTERNET DRAFT Keio University/Sony CSL 4 Masahiro Ishiyama 5 Toshiba 6 Mitsunobu Kunishi 7 Keio University 8 24 June 2003 10 LIN6: A Solution to Mobility and Multi-Homing in IPv6 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC 2026. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other groups 21 may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents, valid for a maximum of six months, 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 LIN6 is a protocol supporting mobility and multi-homing in IPv6. LIN6 37 introduces the node id, not the interface id, for each node. Each node 38 can be identified by its node id no matter where the node is connected 39 and no matter how many interfaces the node has. In the IPv6 layer, 40 64-bit node id called LIN6 ID is used while 128-bit node-id called LIN6 41 generalized ID is used above the Transport layer. TCP connections and 42 security associations can be preserved even if the node moves to another 43 subnet or the node changes the using interface in a multi-homing 44 environment without modifying TCP or IPsec. In comparison with Mobile 45 IPv6, LIN6 has several advantages in terms of header overhead and fault 46 tolerance. 48 1. Introduction 50 This document describes the protocol specification of 51 LIN6[IEICE01,WPMC01]. We propose LINA (Location Independent Network 52 Architecture) to solve several problems such as mobility and multi- 53 homing by redesigning network architecture and addressing. LIN6 is an 54 application of LINA to IPv6[RFC2460]. LIN6 supports mobility and multi- 55 homing with IPsec[RFC2401] in IPv6. 57 From mobility support viewpoint, LIN6 has several advantages in 58 comparison with Mobile IPv6[MIPv6] as follows: 60 o LIN6 has no header overhead because it does not use any extension 61 headers of IPv6 while Mobile IPv6 uses the Destination Options Header 62 for the Home Address Option and the Routing Header for optimal 63 routing. 65 o LIN6 is more fault tolerant than Mobile IPv6. In Mobile IPv6, the 66 Home Agent cannot be replicated to the subnet other than the home link 67 of the mobile node. LIN6 introduces the Mapping Agent which can be 68 replicated anywhere in the Internet. 70 o LIN6 keeps end-to-end communication model, that is, LIN6 does not use 71 any packet intercepter/forwarder such as the Home Agent of Mobile 72 IPv6. There is no tunneling in LIN6. 74 LIN6 also has several advantages from viewpoint of multi-homing support. 75 Assume that Node-A starts TCP communication with Node-B, a multi-homing 76 node with two network interfaces, by using IPsec. 78 o Node-A can recognize the identity of Node-B by the LIN6 address of 79 Node-B no matter which network interface of Node-B is used. 81 o The same security association (SA) can be used between Node-A and 82 Node-B no matter which network interface of Node-B is used. 84 o The TCP connection and the SA are still available even after the used 85 network interface of Node-B is switched to another during 86 communication. 88 2. Terminology 90 This document uses the following terms. 92 node: 93 The node is the general term to specify the equipment that 94 understands IP in the Internet. The node includes hosts, mobile 95 terminals, routers, and so on. 97 LIN6 ID: 99 The LIN6 ID is assigned to the node and uniquely identifies the 100 node in the Internet. It is 64 bits in length. 102 LIN6 prefix: 103 The LIN6 prefix is a predefined constant value attached to the 104 head of the LIN6 ID to construct the LIN6 generalized ID. 106 LIN6 generalized ID: 107 The LIN6 generalized ID is the identifier of the node used in the 108 transport layer and the upper layers. It is 128 bits in length. 109 The higher 64 bits of the LIN6 generalized ID is the LIN6 prefix 110 and the lower 64 bits is the LIN6 ID. The LIN6 generalized ID is 111 assigned to the node, not to the network interface. Application 112 programs use the LIN6 generalized ID to indicate the target node. 113 TCP establishes the TCP connection between two LIN6 generalized 114 IDs. Note that the LIN6 generalized ID does not appear in the 115 IPv6 header on the link. 117 network prefix: 118 The network prefix indicates the subnet to which the node is 119 connected. It is attached to the head of the LIN6 ID to construct 120 the LIN6 address. 122 LIN6 address: 123 The LIN6 address is assigned to the network interface of the node. 124 The higher 64 bits of the LIN6 address is the network prefix and 125 the lower 64 bits is the LIN6 ID so that the LIN6 address 126 specifies the identifier of the node as well as the point of 127 attachment to the Internet of the node. Note that the LIN6 128 address appears in the IPv6 header on the link and is not passed 129 to the transport layer. 131 stationary address: 132 The stationary address is a LIN6 address assigned to a stationary 133 node that understands LIN6. In the lower half of the stationary 134 address, the Universal/Local bit of EUI-64 is set to zero while 135 that bit in the LIN6 address is set to one. 137 mapping: 138 The mapping is the relation between the LIN6 ID and the network 139 prefix. 141 Mapping Agent: 142 The Mapping Agent (MA) is the function that maintains the mapping 143 of the mobile node. Each mobile node is associated with one or 144 more Mapping Agents. The relation between the LIN6 ID of the 145 mobile node and the address of the Mapping Agent is registered 146 with the DNS. 148 Mapping Cache: 150 The Mapping Cache is the cache for mapping in the node. 152 normal IPv6 address: 153 The aggregatable global unicast address. 155 3. Protocol Overview 157 3.1. Address 159 LIN6 uses two types of network addresses: the LIN6 generalized ID and 160 the LIN6 address. Figure 1 depicts their formats. The LIN6 generalized 161 ID is 128 bits in length and is used in the transport layer and the 162 upper layers. LIN6 generalized ID is the identifier of the node in the 163 transport layer and the upper layers and does not change even if the 164 node moves. The LIN6 address is also 128 bits in length and is used in 165 the network layer. The LIN6 address specifies both the location and the 166 identifier of the node. The network prefix part of the LIN6 address 167 changes when the node moves to anther subnet. The formats of the LIN6 168 generalized ID and the LIN6 address are the same as the format of IPv6 169 aggregatable global unicast address[RFC2374]. 171 <-------- 64 bits --------> <-------- 64 bits -------> 172 LIN6 +---------------------------+--------------------------+ 173 generalized | LIN6 prefix (constant) | LIN6-ID | 174 ID +---------------------------+--------------------------+ 176 +---------------------------+--------------------------+ 177 LIN6 address | network prefix | LIN6-ID | 178 +---------------------------+--------------------------+ 180 aggregatable +--+------+---+------+------+--------------------------+ 181 global unicast |FP|TLA ID|res|NLA ID|SLA ID| Interface ID | 182 address +--+------+---+------+------+--------------------------+ 184 Figure 1: The LIN6 generalized ID and the LIN6 address 186 Both the LIN6 generalized ID and the LIN6 address consist of two fields: 187 the network prefix and the LIN6 ID. Both fields are 64 bits in length. 188 The LIN6 ID is the global unique identifier of the node. EUI-64[EUI64] 189 will be used as LIN6-ID. The network prefix of the LIN6 address 190 indicates the subnet to which the node is connected while that of the 191 LIN6 generalized ID is the constant value and is called the LIN6 prefix. 192 In other words, the LIN6 address indicates both the location and the 193 identifier of the node while the LIN6 generalized only identifies the 194 node. Thus, the LIN6 generalized ID is used in the transport layer and 195 the upper layers to identify the node, and the LIN6 address is used in 196 the network layer to indicate both the location and the identifier of 197 the node. Note that the LIN6 ID and the LIN6 generalized ID are 198 assigned per node while the LIN6 address is assigned per network 199 interface. Also note that the normal IPv6 address, i.e., the 200 aggregatable global unicast address, is assigned to the network 201 interface of the node in addition to the LIN6 address. 203 3.2. Address Processing 205 Figure 2 shows the procedures of address processing. As mentioned 206 above, the LIN6 generalized ID consists of the (constant) LIN6 prefix 207 and the LIN6 ID. In packet transmission, the transport layer specifies 208 the LIN6 generalized ID of the destination node to the network layer. 209 The network layer obtains the network prefix, i.e., the current 210 location, of the destination node by some means (see Section 3.3). The 211 network layer concatenates the obtained network prefix and the LIN6 ID 212 contained in the LIN6 generalized ID to create the LIN6 address of the 213 destination node. 215 In packet reception, the source address field of the packet contains the 216 LIN6 address of the source node. The network layer concatenates the 217 LIN6 prefix and the LIN6 ID contained in the LIN6 address of the source 218 node to create the LIN6 generalized ID, and then the network layer 219 notifies the transport layer of the packet reception with the LIN6 220 generalized ID of the source node. Thus, from the transport layer's 221 viewpoint, communication is done between the two LIN6 generalized IDs. 223 224 +--------------+--------------+ +--------------+--------------+ 225 | LIN6 prefix | LIN6 ID | | LIN6 prefix | LIN6 ID | 226 +--------------+--------------+ +--------------+--------------+ 227 transport | LIN6 generalized ID ^ 228 layer | | 229 ----------------|---------------------------------|---------------- 230 network layer | | 231 v | 232 +--------------+--------------+ +--------------+--------------+ 233 | LIN6 prefix | LIN6 ID | | LIN6 prefix | LIN6 ID | 234 +--------------+--------------+ +--------------+--------------+ 235 | ^ 236 +------------+ | | 237 | mapping | | +------>+<------+ 238 v | v | | 239 +--------------+ +--------------+ +--------------+ +--------------+ 240 |network prefix| | LIN6 ID | | LIN6 prefix | | LIN6 ID | 241 +--------------+ +--------------+ +--------------+ +--------------+ 242 | | ^ 243 +------>+<-------+ | 244 | | 245 v | 246 +--------------+--------------+ +--------------+--------------+ 247 |network prefix| LIN6 ID | |network prefix| LIN6 ID | 248 +--------------+--------------+ +--------------+--------------+ 249 | LIN6 address ^ 250 | | 251 ----------------|----------------------------------|---------------- 252 data link v | 253 layer 255 Figure 2: Address processing 257 3.3. Distinction between the LIN6 Address and the Normal IPv6 Address 259 As shown on the right side of Figure 2, the receiving node must 260 distinguish the LIN6 address from the normal IPv6 address to decide 261 whether address conversion must be done. From address format viewpoint, 262 however, the LIN6 address is indistinguishable from the normal IPv6 263 address. (i.e., LIN6 is fully compatible with IPv6.) There are some 264 methods to distinguish the two address types. As a temporary solution, 265 LIN6 employs a special value as a part of the LIN6 ID. To distinguish 266 the LIN6 address, Sony CSL obtained the OUI value 0x00-01-4A of 267 EUI-64[EUI64]. According to the IPv6 addressing scheme, the 268 Universal/Local bit of EUI-64 must be reversed in the global IPv6 269 address. Thus, if the upper 24 bits of the lower 64 bits of the IPv6 270 address is 0x02-01-4A, the IPv6 address is the LIN6 address. 272 3.4. Stationary Address 274 As mentioned above, LIN6 introduces the 64-bit LIN6 ID as the node 275 identifier. The identity of a mobile node is guaranteed by the LIN6 ID 276 even if the network prefix of the node changes. In case of a stationary 277 node the entire 128-bit can be used as the node identifier because the 278 network prefix does not usually change. Thus, LIN6 introduces another 279 type of LIN6 address, the stationary address which is assigned to a 280 stationary node. 282 The upper half of the stationary address is the normal network prefix. 283 To distinguish the stationary address, the first three bytes of the 284 lower half of the stationary address must be a special value such as the 285 OUI value of Sony CSL in which the Universal/Local bit is set to zero. 286 The remaining five bytes of the lower half of the stationary address can 287 be generated randomly by the stationary node. Upon generating a 288 stationary address, the Duplicate Address Detection procedure must be 289 done. 291 By introducing the stationary address, it is not required to assign the 292 LIN6 ID to stationary nodes. The LIN6 ID must be assigned only to 293 mobile nodes. This reduces administrative workload for LIN6 ID 294 assignment. 296 Upon transmission, if the destination address is a stationary address, 297 this address is set to the destination address field of the IPv6 header 298 without the address processing described in Section 3.2. Upon 299 reception, if the source address is a stationary address, this address 300 is passed to the upper layer without the address processing. 302 3.5. Mapping Agent 304 The relation between the LIN6 ID and the network prefix is called 305 mapping. LIN6 introduces the Mapping Agent (MA) to maintain the mapping 306 of the mobile node. The Mapping Agent maintains the mapping of the 307 mobile node and replies to queries about mapping. Each mobile node is 308 associated with one or more Mapping Agents. When the network prefix of 309 the mobile node changes, i.e., when the mobile node moves, the mobile 310 node registers the new network prefix with one of the Mapping Agents 311 that maintain the mapping of the mobile node. Consistency among the 312 databases on the Mapping Agents must be kept by some procedures. These 313 procedures are beyond of the scope of this document. 315 It can be assumed that the relation between the mobile node and its 316 Mapping Agent is almost static in contrast to the mapping of the mobile 317 node. LIN6 makes use of the Domain Name System (DNS) to maintain the 318 relation between the mobile node and its Mapping Agents. A new DNS 319 record MA is introduced to register the address of the Mapping Agent of 320 the mobile node with the DNS database. 322 3.6. Communication Procedure 324 The LIN6 Communication procedure is shown in Figure 3. Assume that 325 Node-A tries to send a packet to Node-B. For simplicity, Node-A and 326 Node-B are associated with only a single Mapping Agent, respectively 327 (MA-A and MA-B). The communication procedure is as follows: 329 1. At first, Node-A and Node-B register their network prefixes with MA- 330 A and MA-B, respectively. The Authentication Header of IPv6 is used 331 in registration. 333 2. The Node-A obtains the address (AAAA record) of Node-B from the name 334 server by indicating the domain name of Node-B. The obtained address 335 is the LIN6 generalized ID of Node-B. 337 3. Node-A obtains the address of MA-B from the name server by indicating 338 the LIN6 generalized ID of Node-B. 340 4. Node-A obtains the network prefix of Node-B from MA-B by indicating 341 the LIN6 ID of Node-B. 343 5. Node-A sends a packet to Node-B. 345 6. To avoid impersonation, Node-B must obtain the network prefix of 346 Node-A from MA-A. Node-B obtains the address of MA-A from the name 347 server by indicating 348 the LIN6 generalized ID of Node-A. 350 7. Node-B obtains the network prefix of Node-A from MA-A by indicating 351 the LIN6 ID of Node-A. 353 8. Node-B sends a packet to Node-A. 355 NS: Name Server +------+ 1 356 MA: Mapping Agent | MA-B | <---------------+ 357 +------+ | 358 ^ | 359 4| | 360 V 5 | 361 +----+ 2, 3 +------+ ----------> +------+ 6 +----+ 362 | NS | <---------> |Node-A| |Node-B| <---------> | NS | 363 +----+ +------+ <---------- +------+ +----+ 364 | 8 ^ 365 | 7| 366 | V 367 | 1 +------+ 368 +--------------->| MA-A | 369 +------+ 371 Figure 3: Communication procedures 373 3.7. IPsec Operation 375 In the sending node, IPsec is processed as follows. When the packet is 376 passed from the transport layer, the source and destination address 377 fields in the IPv6 header contain LIN6 generalized IDs. The security 378 association is decided by using the destination LIN6 generalized ID, and 379 then IPsec calculation is executed. After that, the source and 380 destination LIN6 generalized IDs are converted to LIN6 addresses. 382 In the receiving node, IPsec is processed as follows. Upon packet 383 reception, the source and destination address fields of IPv6 header 384 contain LIN6 addresses. First, these LIN6 addresses are converted to 385 LIN6 generalized IDs. The security association is decided by using the 386 destination LIN6 generalized ID, and then IPsec calculation is executed. 388 3.8. Mobility Support 390 3.8.1. Mobility Support Type 1: Basic Procedure 392 Mobility support in LIN6 is shown in Figure 4. Assume that SAs are 393 established between the mobile node (MN) and the correspondent node 394 (CN), and between the MN and the MA. This mechanism relies on the SA to 395 avoid impersonation. 397 1. The MN registers its current network prefix with the Mapping Agent 398 (MA). The Authentication Header is used in this registration. 400 2. The CN obtains the LIN6 address and MA's address from the name 401 server. 403 3. The CN obtains MN's network prefix from the MA. 405 4. The CN sends a packet to the MN. The source address of this packet 406 is the normal IPv6 address because the CN is stationary in this case. 408 5. The MN returns a packet to the CN. The source address of the 409 received packet is used as the destination address of the return 410 packet because the source address of the received packet is the 411 normal IPv6 address. 413 6. The MN moves to another subnet. 415 7. The MN registers the new network prefix with the MA and the CN. The 416 Authentication Header is used in these registrations. 418 8. The CN sends a packet to the MN. 420 +----+ 4 +----+ 6 421 +----+ 2 | | --------> | MN | -----+ 422 | NS |<---->| | <-------- | | | 423 +----+ | CN | 5 +----+ V 424 | | 7 | +----+ 425 | | <-----------|------ | MN | 426 | | ------------|-----> | | 427 +----+ 8 | +----+ 428 ^ | | 429 3| | | 430 V | | 431 +----+ 1 | | 432 | MA | <-----------+ 7 | 433 | | <---------------------+ 434 +----+ 436 Figure 4: Mobility Support 438 3.8.2. Mobility Support Type 2: Mapping Refresh Message 440 Figure 5 shows mobility support in which there is no SA between the MN 441 and the CN. In terms of avoiding impersonation, this mechanism is as 442 secure as the current internet where every node trusts the DNS. This 443 mechanism relies on the DNS and the MA. Steps 1 to 6 are the same as 444 Figure 4. 446 7. The MN registers the new network prefix with the MA. The 447 Authentication Header is used in this registration. 449 8. The MN sends the Mapping Refresh Message to CN to notify the CN of 450 the event that the MN has moved. 452 9. The CN obtains the new network prefix of the MN from the MA. 454 10. The CN sends a packet to the MN. 456 +----+ 4 +----+ 6 457 +----+ 2 | | --------> | MN | -----+ 458 | NS |<---->| | <-------- | | | 459 +----+ | CN | 5 +----+ V 460 | | 8 | +----+ 461 | | <-----------|------ | MN | 462 | | ------------|-----> | | 463 +----+ 10 | +----+ 464 ^ ^ | | 465 3| |9 | | 466 V V | | 467 +----+ 1 | | 468 | MA | <-----------+ 7 | 469 | | <---------------------+ 470 +----+ 472 Figure 5: Mobility Support (no SA between MN and CN) 474 3.8.3. Mobility Support Type 3: Cookie 476 Figure 6 shows mobility handling mechanism that uses a cookie for 477 authentication. This mechanism is effective in the environment in which 478 there is no possibility of eavesdropping. For example, messages are 479 encrypted on wireless links and wired links are well managed to avoid 480 eavesdropping. Steps 1 and 2 are the same as Figure 4. 482 3. The CN receives MN's network prefix from the MA. At the same time, 483 the CN notifies the MA of CN's cookie. 485 4. The MA notifies the MN of CN's cookie. This notification uses IPsec 486 Authentication Header. 488 5. The CN sends a packet to the MN. 490 6. The MN returns a packet to the CN. 492 7. The MN moves to another subnet. 494 8. The MN registers the new network prefix with the CN. This 495 registration includes CN's cookie received from the MA. The CN can 496 trust this registration if the cookie sent to the MA and the cookie 497 received from the MN are the same. 499 9. The MN registers the new network prefix with the MA. The 500 Authentication Header is used in this registration. 502 10. The CN sends a packet to the MN. 504 +----+ 5 +----+ 7 505 +----+ 2 | | --------> | MN | -----+ 506 | NS |<---->| | <-------- | | | 507 +----+ | CN | 6 +----+ V 508 | | 8 | ^ +----+ 509 | | <----------|-|----- | MN | 510 | | -----------|-|----> | | 511 +----+ 10 | | +----+ 512 ^ | | | 513 3| | |4 | 514 V | | | 515 +----+ 1 | | | 516 | MA | <----------+ | | 517 | | -------------+ 9 | 518 | | <---------------------+ 519 +----+ 521 Figure 6: Mobility Support (simplified authentication) 523 3.9. Multi-Homing Support 525 Figure 7 shows multi-homing support in LIN6. In the figure, Node-B is a 526 multi-homing host which has two network interfaces. Node-A and Node-B 527 have the LIN6 generalized ID, "LIN6_P+ID_A" and "LIN6_P+ID_B", 528 respectively, where "LIN6_P" is the LIN6 Prefix, and "ID_A" and "ID_B" 529 are the identifiers of Node-A and Node-B, respectively. Node-A has the 530 LIN6 address, "P_A+ID_A", where "P_A" is the network prefix of Node-A. 531 Node-B has two LIN6 addresses, "P_B1+ID_B" and "P_B2+ID_B", where "P_B1" 532 and "P_B2" are the network prefixes of Node-B corresponding to the two 533 network interfaces. 535 1. Node-A establishes a TCP connection with Node-B by using IPsec. This 536 TCP connection is established between {LIN6_P+ID_A, port_A} and 537 {LIN6_P+ID_B, port_B}. The SA of IPsec is established between 538 "LIN6_P+ID_A" and "LIN6_P+ID_B". Assume that Node-A obtains "P_B1" 539 and "P_B2" as the network prefixes of Node-B and selects "P_B1". The 540 packet in the TCP connection has "P_A+ID_A" and "P_B1+ID_B" as the 541 source/destination addresses. The packets in the TCP connection 542 traverse Path_A in the figure. 544 2. Assume that Path_A crashes due to some reason, and ICMP Unreach is 545 returned to Node-A. 547 3. Node-A knows that Path_A is unavailable and selects "P_B2" as the 548 network prefix of Node-B. The packet in the TCP connection has 549 "P_A+ID_A" and "P_B2+ID_B" as the source/destination addresses. The 550 packets in the TCP connection traverse Path_B in the figure. 551 Although the LIN6 address of Node-B changes, the TCP connection and 552 the SA are still available even after the path change because the TCP 553 connection is established between {LIN6_P+ID_A, port_A} and 554 {LIN6_P+ID_B}, and the SA is established between "LIN6_P+ID_A" and 555 "LIN6_P+ID_B". 557 1. (old) TCP connection 558 +-----------------------------+ 559 | | 560 | +-------X 2. ICMP Unreach | 561 <---+ | | 562 | +=====================+ | 563 <---- + | Path_A "P_B1"| V 564 +------+ | +------+ 565 |Node-A|==========+ |Node-B| "ID_B" 566 +------+ "P_A" | +------+ 567 "ID_A" | Path_B "P_B2"| ^ 568 <-----+ +=====================+ | 569 | | 570 +---------------------------+ 571 3. (new) TCP connection 573 Figure 7: Multi-Homing Support 575 4. Packet Formats 577 4.1. Data Packet 579 LIN6 uses the normal IPv6 header in which the LIN6 addresses are used in 580 the source address field and the destination address field. Figure 8 581 shows the format of the normal IPv6 header. 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 |version| Traffic Class | Flow Label | 585 +-------+---------------+-------+---------------+---------------+ 586 | Payload Length | Next Header | Hop Limit | 587 +-------------------------------+---------------+---------------+ 588 | | 589 + + 590 | Source Address | 591 + (LIN6 Address) + 592 | | 593 + + 594 | | 595 +---------------------------------------------------------------+ 596 | | 597 + + 598 | Destination Address | 599 + (LIN6 Address) + 600 | | 601 + + 602 | | 603 +---------------------------------------------------------------+ 605 Figure 8: IPv6 (LIN6) header format 607 4.2. Mapping Update and Reply Messages 609 When a mobile node moves to another subnet, i.e., when the network 610 prefix of the mobile node changes, the mobile node sends the Mapping 611 Update Message to the Mapping Agent and the correspondent nodes. Upon 612 receiving the Mapping Update Message, the Mapping Agent or the 613 correspondent node returns the Mapping Reply Message to the mobile node. 614 The Mapping Update and Reply Messages are UDP packets. The 615 Authentication Header of IPv6 must be included in the Mapping Update 616 Message to avoid illegal mapping update. Figure 9 shows the formats of 617 the Mapping Update and Reply Messages. 619 0 0 1 3 620 0 8 6 1 621 +-->+--------+--------+-----------------+ 622 | | Type | code | Flags | 623 | +--------+--------+-----------------+ 624 | | Sequence Number | 625 | +-----------------------------------+ 626 | | | 627 | + Network Prefix + 628 | | | 629 +----------------------+ | +-----------------------------------+ 630 | IPv6 Base Header | | | | 631 +----------------------+ | + LIN6 ID + 632 |Authentication Header | | | | 633 +----------------------+ | +-----------------------------------+ 634 | UDP Header | | | Timestamp | 635 +----------------------+--+ +-----------------------------------+ 636 |Mapping Update Request| | Lifetime | 637 +----------------------+----->+-----------------------------------+ 638 (a) Mapping Update 639 Request Message 641 +----------------------+ 642 | IPv6 Base Header | 643 +----------------------+ 0 0 1 3 644 |Authentication Header | 0 8 6 1 645 +----------------------+ +-->+--------+--------+-----------------+ 646 | UDP Header | | | Type | Code | Flags | 647 +----------------------+--+ +--------+--------+-----------------+ 648 | Mapping Update Reply | | Sequence Number | 649 +----------------------+----->+-----------------------------------+ 650 (b) Mapping Update 651 Reply Message 653 Figure 9 Mapping Update Request/Reply formats 655 Source Address: the LIN6 address of the source node. 657 Destination Address: the LIN6 address of the destination node. 659 Source Port: TBD. 661 Destination Port: TBD. 663 Type: 664 0x01: update request 665 0x02: update reply 667 Code: 669 0x00: succeeded 670 0x01: authentication failed 671 0x02: ... 673 Flags: TBD 675 Sequence Number: 676 the source node of the Mapping Update Request Message assigns this 677 field a sequence number. This value is copied to this field of 678 the Mapping Update Reply Message. 680 LIN6 ID: the LIN6 ID of the source node. 682 Network Prefix: the current network prefix of the source node. 684 Timestamp: the current time. 686 Lifetime: the period of time in which this mapping is valid. 688 4.3. MA Query and Reply Messages 690 When a node wants to send a packet to a mobile node, the node sends the 691 MA Query Message to the Mapping Agent to obtain the current network 692 prefix of the mobile node. When the Mapping Agent receives the MA Query 693 Message, it returns the MA Reply Message to the node to notify the 694 network prefix of the mobile node. Figure 10 shows the format of the MA 695 Query and Reply Messages. 697 0 0 1 3 698 0 8 6 1 699 +-->+--------+--------+-----------------+ 700 | | Type | Code | Flags | 701 | +--------+--------+-----------------+ 702 | | Sequence Number | 703 | +-----------------------------------+ 704 | | | 705 | + Network Prefix + 706 | | | 707 | +-----------------------------------+ 708 | | | 709 +----------------+ | + LIN6 ID + 710 |IPv6 Base Header| | | | 711 +----------------+ | +-----------------------------------+ 712 | UDP Header | | | Timestamp | 713 +----------------+--+ +-----------------------------------+ 714 | MA Query/Reply | | Lifetime | 715 +----------------+----->+-----------------------------------+ 717 Figure10 MA Query/Reply Message format 719 Source Address: the LIN6 address of the source node. 721 Destination Address: the LIN6 address of the destination node. 723 Source Port: TBD. 725 Destination Port: TBD. 727 Type: 728 0x01: query 729 0x02: reply 731 Code: 732 0x00: succeeded 733 0x01: no mapping exists 734 0x02: ... 736 Flags: TBD. 738 Sequence Number: 739 the source node of the MA Query Message assigns this field a 740 sequence number. This value is copied to this field of the MA 741 Reply Message. 743 LIN6 ID: the LIN6 ID of the target node. 745 Network Prefix: the current network prefix of the target node. 747 Timestamp: the timestamp of this mapping. 749 Lifetime: the period of time in which this mapping is valid. 751 4.4. Mapping Refresh Message 753 Figure 11 shows the format of the Mapping Refresh Message. When the 754 network prefix of a node changes due to, for example, node movement, if 755 there is no security association between the node and the correspondent 756 node, the node sends the Mapping Refresh Message to the correspondent 757 node. Upon receiving the Mapping Refresh Message, the receiving node 758 sends the MA Query Message to obtain the new network prefix of the node 759 sending the Mapping Refresh Message. 761 0 0 1 3 762 0 8 6 1 763 +-->+--------+--------------------------+ 764 | | Type | reserved | 765 +----------------+ | +--------+--------------------------+ 766 |IPv6 Base Header| | | | 767 +----------------+ | + LIN6 ID + 768 | UDP Header | | | | 769 +----------------+--+ +-----------------------------------+ 770 |Mapping Refresh | | Timestamp | 771 +----------------+----->+-----------------------------------+ 773 Figure11 Mapping Refresh Message format 775 Source Address: the LIN6 address of the source node. 777 Destination Address: the LIN6 address of the destination node. 779 Source Port: TBD. 781 Destination Port: TBD. 783 Type: TBD 785 LIN6 ID: the LIN6 ID of the target node. 787 Timestamp: the timestamp of this mapping. 789 5. Processing on the Mobile Node 791 5.1. Bootstrap 793 When the mobile node is powered on, it obtains the network prefix of the 794 subnet to which it is connected by sending the Router Solicitation 795 Message[RFC2461] and receiving the Router Advertisement Message. Next, 796 the mobile node sends a DNS query packet to obtain the address of the 797 Mapping Agent that maintains the mapping of the mobile node. Next, the 798 mobile node establishes a security association of IPsec[RFC2401] with 799 the Mapping Agent. Next, the mobile node sends the Mapping Update 800 Request Message to the Mapping Agent to register the current network 801 prefix and receives the Mapping Update Reply Message. 803 5.2. Processing on Movement 805 The mobile node detects the change of the point of attachment to the 806 Internet by some mechanisms, for example, 1) interrupt by hardware, 2) 807 upcall from the link layer, and 3) router advertisement message. When 808 the mobile node detects a location change, first, it sends the Router 809 Solicitation Message and receives the Router Advertisement Message to 810 obtain the network prefix of the subnet to which the mobile node is 811 connected. Next, the mobile node sends the Mapping Update Request 812 Message to the Mapping Agent to notify the current network prefix. The 813 mobile node also sends the Mapping Update Request Message to the 814 correspondent nodes with which it has a security association. The 815 Mapping Update Request Message must include the Authentication Header. 816 The mobile node sends the Mapping Refresh Message to the correspondent 817 nodes with which it has no security association. 819 6. Processing on Mapping Agent 821 Upon receiving the Mapping Update Request Message from the mobile node, 822 first, the Mapping Agent makes it sure that the Authentication Header is 823 correct. If authentication fails, the Mapping Agent returns the Mapping 824 Update Reply Message with the error code Authentication Failed. If 825 authentication succeeds, the Mapping Agent updates the mapping of the 826 mobile node and returns the Mapping Update Reply Message to the mobile 827 node. 829 If the mobile node is associated with two or more Mapping Agents, 830 consistency among the databases on the Mapping Agents must be kept by 831 some procedures. These procedures are beyond of the scope of this 832 document. 834 7. Packet Transmission and Reception 836 7.1. Packet Transmission 838 When the network layer receives a packet transmission request from the 839 transport layer, the network layer makes sure that the destination 840 address passed from the TCP/UDP is a LIN6 generalized ID or a normal 841 IPv6 address by checking the upper 64 bits of the destination address. 842 If the destination address is a normal IPv6 address, the network layer 843 executes the normal IPv6 transmission procedure. If the destination 844 address is a LIN6 generalized ID, the network layer executes the LIN6 845 procedure described below. 847 The network layer extracts the LIN6 ID from the LIN6 generalized ID and 848 searches the Mapping Cache for the network prefix by using the LIN6 ID 849 as the key. If the network prefix is found, the network layer 850 concatenates the network prefix and the LIN6 ID to create the LIN6 851 address of the destination node. After that, the network layer executes 852 the normal IPv6 transmission procedure. 854 If the network prefix of the destination node is not found in the 855 Mapping Cache, the node keeps the packet waiting for transmission, and 856 then sends the MA Query Message to the Mapping Agent to obtain the 857 network prefix. If the source node does not know the address of the 858 Mapping Agent, it obtains the Mapping Agent's address from the name 859 server by indicating the LIN6 ID of the destination address. Upon 860 receiving the MA Reply Message, the node creates the LIN6 address of the 861 destination node, and then executes the normal IPv6 transmission 862 procedure. 864 7.2. Packet Reception 866 When the network layer receives a packet from the link layer, first the 867 network layer makes sure that the source address of the IPv6 header is a 868 LIN address or a normal IPv6 address. Refer to the next subsection 869 about how to distinguish between the LIN6 address and the normal IPv6 870 address. If the source address is the normal IPv6 address, the network 871 layer executes the normal IPv6 reception procedure. 873 If the source address is the LIN6 address, the network layer removes the 874 network prefix part of the LIN6 address, and then attaches the LIN6 875 prefix to create the LIN6 generalized ID of the source node. After 876 that, the network layer executes the normal IPv6 reception procedure. 878 7.3. Mapping Refresh Message Reception 880 When a node receives the Mapping Refresh Message, it sends the MA Query 881 Message to the Mapping Agent of the node sending the Mapping Refresh 882 Message. If the node does not know the address of the Mapping Agent, it 883 obtains the Mapping Agent's address from the name server by indicating 884 the LIN6 ID of the node sending the Mapping Refresh Message. 886 8. Intellectual Property Right 888 There are mechanisms included in the following pending patent 889 applications that have been FILED to the Japanese Patent office. 891 - Japanese application No.2000-005560 Sony 893 - Japanese application No.2000-036693 Toshiba 895 These include the mapping agent and address processing mechanisms. It 896 must be stressed that they have only been filed, and have not been 897 granted. They have been filed separately by Sony and Toshiba. 899 We really intend to contribute to development of the Internet community 900 and to keep a good relationship with IETF. And our primary concern is to 901 promote our technology so that others may feel it is useful and 902 worthwhile in the spirit of the IETF. 904 If indeed the mechanisms are granted as patents, the patents will be 905 licensed under reasonable and non-discriminatory conditions to any 906 person who wants to implement the mechanisms. 908 Author's Address 910 o Fumio Teraoka 911 Keio University 912 3-14-1 Hiyoshi, Kohoku-ku, Yokohama, Kanagawa 223-8522, Japan. 913 Phone: +81-45-566-1425 914 and 915 Sony Computer Science Laboratories, Inc. 916 3-14-13 Higashigotanda, Shinagawa-ku, Tokyo 141-0022, Japan. 917 Phone: +81-3-5448-4380 918 Email: tera@wide.ad.jp 920 o Masahiro Ishiyama 921 R&D Center, Toshiba. 922 1 Komukai Toshiba-Cho, Saiwai-Ku, Kawasaki, Kanagawa 212-8582, Japan. 923 Phone: +81-44-549-2238 924 Email: masahiro@isl.rdc.toshiba.co.jp 926 o Mitsunobu Kunishi 927 Keio University 928 3-14-1 Hiyoshi, Kohoku-ku, Yokohama, Kanagawa 223-8522, Japan. 929 Phone: +81-45-566-1425 930 Email: kunishi@tokoro-lab.org 932 References 934 [IEICE01] M. Ishiyama, M. Kunishi, K. Uehara, H. Esaki, and F. Teraoka. 935 LINA: A New Approach to Mobility Support in Wide Area Networks, 936 IEICE Transactions on Communication, Vol. E84-B no. 8, Aug. 2001. 938 [WPMC01] M. Ishiyama, M. Kunishi, K. Uehara, and F. Teraoka. An Analysis 939 of Mobility Handling in LIN6. In Proc. of 4th International Sym- 940 posium on Wireless Personal Multimedia Communications, Sep. 2001. 942 [RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 943 Specification. RFC 2460, Dec. 1998. 945 [MIPv6] C. Perkins. Mobility Support in IPv6. Internet Draft draft-ietf- 946 mobileip-ipv6-14.txt, Jul. 2001. 948 [RFC2401] S. Kent and R. Atkinson. Security Architecture for the Internet 949 Protocol. RFC 2401, Nov. 1998. 951 [RFC2374] R. Hinden, M. O'Dell, and S. Deering. An IPv6 Aggregatable 952 Global Unicast Address Format. RFC 2374, Jul, 1998 954 [EUI64] IEEE. Guidelines for 64-bit Global Identifier (EUI-64) Registra- 955 tion Authority, http://standards.ieee.org/regauth/oui/tutori- 956 als/EUI64.html, 1997.