idnits 2.17.1 draft-teraoka-mobility-lin6-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 156 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC2460], [MIPv6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (8 December 2000) is 8539 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: 'ID-MIPv6' is mentioned on line 69, but not defined == Missing Reference: 'RFC2461' is mentioned on line 498, but not defined ** Obsolete undefined reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 ** 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: 11 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Fumio Teraoka 2 INTERNET DRAFT Sony CSL 3 Masahiro Ishiyama 4 Toshiba 5 Keisuke Uehara 6 Keio University 7 Mitsunobu Kunishi 8 Keio University 9 Hiroshi Esaki 10 University of Tokyo 11 8 December 2000 13 LIN6: Mobility Support in IPv6 based on End-to-End Communication Model 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC 2026. 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other groups 24 may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents, valid for a maximum of six months, 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference material 29 or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes the protocol specification of LIN6. LIN6 40 supports both macro and micro mobility in IPv6[RFC2460]. LIN6 has 41 several advantages in comparison with Mobile IPv6[MIPv6] as follows: 43 o LIN6 has no header overhead because it does not use any extension 44 headers of IPv6 while Mobile IPv6 uses the Destination Options 45 Header for the Home Address Option and the Routing Header. 47 o LIN6 is more fault tolerant than Mobile IPv6. In Mobile IPv6, the 48 Home Agent cannot be replicated to the subnet other than the home 49 link of the mobile node. LIN6 introduces the Mapping Agent which 50 can be replicated anywhere in the Internet. 52 o LIN6 keeps end-to-end communication model, that is, LIN6 does not 53 use any packet intercepter/forwarder such as the Home Agent of 54 Mobile IPv6. There is no tunneling in LIN6. 56 1. Introduction 58 The following two functions must be provided to achieve transparent 59 mobility in the network layer such as IPv6. 61 o location independent paging: the correspondent node must be able 62 to send a packet by specifying the immutable address of the mobile 63 node regardless of the location of the mobile node. 65 o TCP connection continuity: TCP connections established between the 66 correspondent node and the mobile node must be preserved even if 67 the mobile node moves to another subnet. 69 In IETF, Mobile IPv6[ID-MIPv6] is being standardized to support 70 transparent mobility in IPv6. However, Mobile IPv6 has several 71 problems. First, since Mobile IPv6 makes use of extension headers of 72 IPv6, it has large header overhead. For example, the header overhead 73 becomes 48 bytes in size when two mobile nodes communicate with each 74 other. Second, the location of the Home Agent is restricted by the home 75 address of the mobile node, that is, the Home Agent must be put on the 76 home network of the mobile node. This restriction makes it difficult to 77 replicate the home agent on other subnets for fault tolerance. In 78 addition, the correspondent node cannot communicate with the mobile node 79 if the home agent is connected beyond the firewall. Third, Mobile IPv6 80 requires Security Association of IPsec[RFC2401] between the 81 correspondent node and the mobile node for optimal routing. It is very 82 difficult to Establish Security association between two nodes of any 83 combination. LIN6 does not require Security Association between the 84 mobile node and the correspondent node for optimal routing. 86 We propose LINA (Location Independent Network Architecture) to support 87 transparent mobility in the network layer by redesigning network 88 architecture such as address structure. LIN6 is an application of LINA 89 to IPv6. LIN6 has no header overhead because it uses no extension 90 headers. The Mapping Agent (see Section XX) can be put anywhere in the 91 Internet regardless of the address of the mobile node. This improves 92 fault tolerance. In a firewall environment, communication with the 93 mobile node is available if the correspondent node and the mobile node 94 are connected to the same region divided by the firewall. 96 2. Terminology 98 This document uses the following terms. 100 node: 101 The node is the general term to specify the equipment that 102 understands IP in the Internet. The node includes hosts, mobile 103 terminals, routers, and so on. 105 LIN6 ID: 106 The LIN6 ID is assigned to the node and uniquely identifies the 107 node in the Internet. It is 64 bits in length. 109 LIN6 prefix: 110 The LIN6 prefix is a predefined constant value attached to the 111 head of the LIN6 ID to construct the LIN6 generalized ID. 113 LIN6 generalized ID: 114 The LIN6 generalized ID is the identifier of the node used in the 115 transport layer and the upper layers. It is 128 bits in length. 116 The higher 64 bits of the LIN6 generalized ID is the LIN6 prefix 117 and the lower 64 bits is the LIN6 ID. The LIN6 generalized ID is 118 assigned to the node, not to the network interface. Application 119 programs use the LIN6 generalized ID to indicate the target node. 120 TCP establishes the TCP connection between two LIN6 generalized 121 IDs. Note that the LIN6 generalized ID does not appear in the 122 IPv6 header on the link. 124 network prefix: 125 The network prefix indicates the subnet to which the node is 126 connected. It is attached to the head of the LIN6 ID to construct 127 the LIN6 address. 129 LIN6 address: 130 The LIN6 address is assigned to the network interface of the node. 131 The higher 64 bits of the LIN6 address is the network prefix and 132 the lower 64 bits is the LIN6 ID so that the LIN6 address 133 specifies the identifier of the node as well as the point of 134 attachment to the Internet of the node. Note that the LIN6 135 address appears in the IPv6 header on the link and is not passed 136 to the transport layer. 138 mapping: 139 The mapping is the relation between the LIN6 ID and the network 140 prefix. 142 Mapping Agent: 143 The Mapping Agent (MA) is the function that maintains the mapping 144 of the mobile node. Each mobile node is associated with one or 145 more Mapping Agents. The relation between the LIN6 ID of the 146 mobile node and the address of the Mapping Agent is registered 147 with the DNS. 149 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|LNA 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 creation. As mentioned above, 206 the LIN6 generalized ID consists of the LIN6 prefix and the LIN6 ID. In 207 packet transmission, the transport layer specifies the LIN6 generalized 208 ID of the destination node to the network layer. The network layer 209 obtains the network prefix, i.e., the current location, of the 210 destination node by some means (see Section 3.3). The network layer 211 concatenates the obtained network prefix and the LIN6 ID contained in 212 the LIN6 generalized ID to create the LIN6 address of the destination 213 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. Mapping Agent 259 The relation between the LIN6 ID and the network prefix is called 260 mapping. LIN6 introduces the Mapping Agent (MA) to maintain the mapping 261 of the mobile node. The Mapping Agent maintains the mapping of the 262 mobile node and replies to queries about mapping. Each mobile node is 263 associated with one or more Mapping Agents. When the network prefix of 264 the mobile node changes, i.e., when the mobile node moves, the mobile 265 node registers the new network prefix with one of the Mapping Agents 266 that maintain the mapping of the mobile node. Consistency among the 267 databases on the Mapping Agents must be kept by some procedures. These 268 procedures are beyond of the scope of this document. 270 It can be assumed that the relation between the mobile node and its 271 Mapping Agent is almost static in contrast to the mapping of the mobile 272 node. LIN6 makes use of the Domain Name System (DNS) to maintain the 273 relation between the mobile node and its Mapping Agents. A new DNS 274 record MA is introduced to register the address of the Mapping Agent of 275 the mobile node with the DNS database. 277 3.4. Communication Procedure 279 The LIN6 Communication procedure is shown in Figure 3. Assume that the 280 correspondent node (CN) wants to send a packet to the mobile node (MN) 281 and that the CN knows the domain name of the MN. For simplicity, the MN 282 is associated with only a single Mapping Agent (MA). The communication 283 procedure is as follows: 285 1. When the MN moves to a subnet and obtains a new network prefix, it 286 registers the new mapping with the MA. 288 2. The CN sends a query packet to the name server (NS) to obtain the 289 address of the MA of the MN by indicating the domain name of the 290 MN. 292 3. The NS returns the address of the MA. 294 4. The CN sends a query packet to the MA to obtain the network prefix 295 of the MN by indicating the LIN6 ID of the MN. 297 5. The MA returns the network prefix of the MN, and then the CN 298 caches the obtained network prefix of the MN. 300 6. The CN sends a packet to the MN. 302 7. The MN sends a packet to the CN. 304 NS: Name Server +----+ 1 305 MA: Mapping Agent | MA | <------------------+ 306 CN: Correspondent node +----+ | 307 MN: Mobile Node ^ | | 308 4| |5 | 309 2 | v 6 | 310 +----+ <-------------- +----+ --------------> +----+ 311 | NS | | CN | | MN | 312 +----+ --------------> +----+ <-------------- +----+ 313 3 7 315 Figure 3: Communication procedures 317 4. Packet Formats 318 4.1. Data Packet 320 LIN6 uses the normal IPv6 header in which the LIN6 addresses are used in 321 the source address field and the destination address field. Figure 4 322 shows the format of the normal IPv6 header. 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 |version| Traffic Class | Flow Label | 326 +-------+---------------+-------+---------------+---------------+ 327 | Payload Length | Next Header | Hop Limit | 328 +-------------------------------+---------------+---------------+ 329 | | 330 + + 331 | Source Address | 332 + (LIN6 Address) + 333 | | 334 + + 335 | | 336 +---------------------------------------------------------------+ 337 | | 338 + + 339 | Destination Address | 340 + (LIN6 Address) + 341 | | 342 + + 343 | | 344 +---------------------------------------------------------------+ 346 Figure 4: IPv6 (LIN6) header format 348 4.2. Mapping Update and Reply Messages 350 When a mobile node moves to another subnet, i.e., when the network 351 prefix of the mobile node changes, the mobile node sends the Mapping 352 Update Message to the Mapping Agent and the correspondent nodes. Upon 353 receiving the Mapping Update Message, the Mapping Agent or the 354 correspondent node returns the Mapping Reply Message to the mobile node. 355 The Mapping Update and Reply Messages are UDP packets. The 356 Authentication Header of IPv6 must be included in the Mapping Update 357 Message to avoid illegal mapping update. Figure 5 shows the formats of 358 the Mapping Update and Reply Messages. 360 0 0 1 3 361 0 8 6 1 362 +-->+--------+--------+-----------------+ 363 | | Type | code | Flags | 364 | +--------+--------+-----------------+ 365 | | Sequence Number | 366 | +-----------------------------------+ 367 | | | 368 | + Network Prefix + 369 | | | 370 +----------------------+ | +-----------------------------------+ 371 | IPv6 Base Header | | | | 372 +----------------------+ | + LIN6 ID + 373 |Authentication Header | | | | 374 +----------------------+ | +-----------------------------------+ 375 | UDP Header | | | Timestamp | 376 +----------------------+--+ +-----------------------------------+ 377 |Mapping Update Request| | Lifetime | 378 +----------------------+----->+-----------------------------------+ 379 (a) Mapping Update 380 Request Message 382 +----------------------+ 383 | IPv6 Base Header | 384 +----------------------+ 0 0 1 3 385 |Authentication Header | 0 8 6 1 386 +----------------------+ +-->+--------+--------+-----------------+ 387 | UDP Header | | | Type | Code | Flags | 388 +----------------------+--+ +--------+--------+-----------------+ 389 | Mapping Update Reply | | Sequence Number | 390 +----------------------+----->+-----------------------------------+ 391 (b) Mapping Update 392 Reply Message 394 Fig. 5 Mapping Update Request/Reply formats 396 Source Address: the LIN6 address of the source node. 398 Destination Address: the LIN6 address of the destination node. 400 Source Port: TBD. 402 Destination Port: TBD. 404 Type: 405 0x01: update request 406 0x02: update reply 408 Code: 410 0x00: succeeded 411 0x01: authentication failed 412 0x02: ... 414 Flags: TBD 416 Sequence Number: 417 the source node of the Mapping Update Request Message assigns this 418 field a sequence number. This value is copied to this field of 419 the Mapping Update Reply Message. 421 LIN6 ID: the LIN6 ID of the source node. 423 Network Prefix: the current network prefix of the source node. 425 Timestamp: the current time. 427 Lifetime: the period of time in which this mapping is valid. 429 4.3. MA Query and Reply Messages 431 When a node wants to send a packet to a mobile node, the node sends the 432 MA Query Message to the Mapping Agent to obtain the current network 433 prefix of the mobile node. When the Mapping Agent receives the MA Query 434 Message, it returns the MA Reply Message to the node to notify the 435 network prefix of the mobile node. Figure 6 shows the format of the MA 436 Query and Reply Messages. 438 0 0 1 3 439 0 8 6 1 440 +-->+--------+--------+-----------------+ 441 | | Type | Code | Flags | 442 | +--------+--------+-----------------+ 443 | | Sequence Number | 444 | +-----------------------------------+ 445 | | | 446 | + Network Prefix + 447 | | | 448 | +-----------------------------------+ 449 | | | 450 +----------------+ | + LIN6 ID + 451 |IPv6 Base Header| | | | 452 +----------------+ | +-----------------------------------+ 453 | UDP Header | | | Timestamp | 454 +----------------+--+ +-----------------------------------+ 455 | MA Query/Reply | | Lifetime | 456 +----------------+----->+-----------------------------------+ 458 Fig.6 MA Query/Reply Message format 460 Source Address: the LIN6 address of the source node. 462 Destination Address: the LIN6 address of the destination node. 464 Source Port: TBD. 466 Destination Port: TBD. 468 Type: 469 0x01: query 470 0x02: reply 472 Code: 473 0x00: succeeded 474 0x01: no mapping exists 475 0x02: ... 477 Flags: TBD. 479 Sequence Number: 480 the source node of the MA Query Message assigns this field a 481 sequence number. This value is copied to this field of the MA 482 Reply Message. 484 LIN6 ID: the LIN6 ID of the target node. 486 Network Prefix: the current network prefix of the target node. 488 Timestamp: the timestamp of this mapping. 490 Lifetime: the period of time in which this mapping is valid. 492 5. Processing on the Mobile Node 494 5.1. Bootstrap 496 When the mobile node is powered on, it obtains the network prefix of the 497 subnet to which it is connected by sending the Router Solicitation 498 Message[RFC2461] and receiving the Router Advertisement Message. Next, 499 the mobile node sends a DNS query packet to obtain the address of the 500 Mapping Agent that maintains the mapping of the mobile node. Next, the 501 mobile node establishes a security association of IPsecNext, the mobile 502 node sends the Mapping Update Request Message to the Mapping Agent to 503 register the current network prefix and receives the Mapping Update 504 Reply Message. 506 5.2. Processing on Movement 508 The mobile node detects the change of the point of attachment to the 509 Internet by some mechanisms, for example, 1) interrupt by hardware, 2) 510 upcall from the link layer, and 3) router advertisement message. When 511 the mobile node detects a location change, first, it sends the Router 512 Solicitation Message and receives the Router Advertisement Message to 513 obtain the network prefix of the subnet to which the mobile node is 514 connected. Next, the mobile node sends the Mapping Update Request 515 Message to the Mapping Agent and the correspondent nodes to notify the 516 current network prefix. The Mapping Update Request Message must include 517 the Authentication Header. 519 6. Processing on Mapping Agent 521 Upon receiving the Mapping Update Request Message from the mobile node, 522 first, the Mapping Agent makes it sure that the Authentication Header is 523 correct. If authentication fails, the Mapping Agent returns the Mapping 524 Update Reply Message with the error code Authentication Failed. If 525 authentication succeeds, the Mapping Agent updates the mapping of the 526 mobile node and returns the Mapping Update Reply Message to the mobile 527 node. 529 If the mobile node is associated with two or more Mapping Agents, 530 consistency among the databases on the Mapping Agents must be kept by 531 some procedures. These procedures are beyond of the scope of this 532 document. 534 7. Packet Transmission and Reception 536 7.1. Packet Transmission 538 When the network layer receives a packet transmission request from the 539 transport layer, the network layer makes sure that the destination 540 address passed from the TCP/UDP is a LIN6 generalized ID or a normal 541 IPv6 address by checking the upper 64 bits of the destination address. 542 If the destination address is a normal IPv6 address, the network layer 543 executes the normal IPv6 transmission procedure. If the destination 544 address is a LIN6 generalized ID, the network layer executes the LIN6 545 procedure described below. 547 The network layer extracts the LIN6 ID from the LIN6 generalized ID and 548 searches the Mapping Cache for the network prefix by using the LIN6 ID 549 as the key. If the network prefix is found, the network layer 550 concatenates the network prefix and the LIN6 ID to create the LIN6 551 address of the destination node. After that, the network layer executes 552 the normal IPv6 transmission procedure. 554 If the network prefix of the destination node is not found in the 555 Mapping Cache, the node keeps the packet waiting for transmission, and 556 then sends the MA Query Message to the Mapping Agent to obtain the 557 network prefix. Upon receiving the MA Reply Message, the node creates 558 the LIN6 address of the destination node, and then executes the normal 559 IPv6 transmission procedure. 561 7.2. Packet Reception 563 When the network layer receives a packet from the link layer, first the 564 network layer makes sure that the source address of the IPv6 header is a 565 LIN address or a normal IPv6 address. Refer to the next subsection 566 about how to distinguish between the LIN6 address and the normal IPv6 567 address. If the source address is the normal IPv6 address, the network 568 layer executes the normal IPv6 reception procedure. 570 If the source address is the LIN6 address, the network layer removes the 571 network prefix part of the LIN6 address, and then attaches the LIN6 572 prefix to create the LIN6 generalized ID of the source node. After 573 that, the network layer executes the normal IPv6 reception procedure. 575 7.3. Distinction between the LIN6 Address and the Normal IPv6 Address 577 From the address format viewpoint, the LIN6 address is indistinguishable 578 from the normal IPv6 address. To distinguish the LIN6 address, Sony CSL 579 obtained the OUI value 0x00-01-4A of EUI-64[EUI64]. Thus, if the upper 580 24 bits of the lower 64 bits of the IPv6 address is 0x00-01-4A, the IPv6 581 address is the LIN6 address. 583 8. Intellectual Property Right 585 This proposal includes patented mechanisms. 587 Author's Address 589 o Fumio Teraoka 590 Sony Computer Science Laboratories, Inc. 591 3-14-13 Higashigotanda, Shinagawa-ku, Tokyo 141-0022, Japan. 592 Phone: +81-3-5448-4380 593 Email: tera@SonyCSL.co.jp 595 o Masahiro Ishiyama 596 R&D Center, Toshiba. 597 1 Komukai Toshiba-Cho, Saiwai-Ku, Kawasaki, Kanagawa 212-8582, Japan. 598 Phone: +81-44-549-2238 599 Email: masahiro@isl.rdc.toshiba.co.jp 601 o Keisuke Uehara 602 Keio University. 603 5322 Endo, Fujisawa, Kanagawa 252-8520, Japan. 604 Phone: +81-466-49-1394 605 Email: kei@wide.ad.jp 607 o Mitsunobu Kunishi 608 Keio University 609 3-14-1 Hiyoshi, Kohoku-ku, Yokohama, Kanagawa 223-0061, Japan. 610 Phone: 611 Email: kunishi@tokoro-lab.org 613 o Hiroshi Esaki 614 University of Tokyo 615 2-11-16 Yayoi, Bunkyo-ku, Tokyo 113-8658, Japan. 616 Phone: +81-3-5684-7303 617 Email: hiroshi@wide.ad.jp 619 References 621 [RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 622 Specification. RFC 2460, Dec. 1998. 624 [MIPv6] C. Perkins. Mobility Support in IPv6. Internet Draft draft- 625 ietf-mobileip-ipv6-13.txt, Nov. 2000. 627 [RFC2401] S. Kent and R. Atkinson. Security Architecture for the Internet 628 Protocol. RFC 2401, Nov. 1998. 630 [RFC2374] R. Hinden, M. O'Dell, and S. Deering. An IPv6 Aggregatable 631 Global Unicast Address Format. RFC 2374, Jul, 1998 633 [EUI64] IEEE. Guidelines for 64-bit Global Identifier (EUI-64) 634 Registration Authority, 635 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, 1997.