idnits 2.17.1 draft-teraoka-mobileip-vip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 115 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 464 has weird spacing: '...Address the ...' == Line 472 has weird spacing: '...Version the ...' == Line 560 has weird spacing: '...Version the ...' == Line 610 has weird spacing: '...Version the ...' == Line 666 has weird spacing: '...Version the ...' -- 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 (December 1, 1995) is 10374 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1541 (ref. '2') (Obsoleted by RFC 2131) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 SonyCSL 4 December 1, 1995 6 Virtual Internet Protocol version 2 (VIPv2) 7 draft-teraoka-mobileip-vip-01.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This memo describes Virtual Internet Protocol version 2 (VIPv2), a 30 protocol for mobility support in IPv4. The basic concept of VIP is 31 separation of identifiers and addresses. TCP/UDP uses the identifier. 32 The identifier is mapped to an address, and then the packet is routed in 33 accordance with the address. End nodes as well as intermediate routers 34 can have authentic mapping information for routing optimization and 35 fault tolerance. 37 1. Introduction 39 A mobility support protocol in IPv4 (Mobile-IP) is under development in 40 IETF. For compatibility with the existing Internet, Mobile-IP makes use 41 of a mechanism called tunneling to forward packets to mobile nodes. 42 However, tunneling has several problems in terms of network architecture 43 as well as network management. 45 VIP[1] is another protocol to support mobility in IPv4. The basic 46 concept of VIP is separation of identifiers and addresses. The 47 identifier of a mobile node never changes regardless of the point of 48 attachment to the Internet, while the address of a mobile node changes 49 when it moves to another subnet. The conventional IP address is the 50 address of a mobile node. VIP introduces "VIP address" as the 51 identifier of a mobile node. The VIP address and the IP address have 52 the same format. TCP/UDP uses the VIP address to specify the target 53 node. The VIP address is mapped to the IP address, and then the packet 54 is routed in accordance with the IP address. 56 For efficient mapping from the VIP address to the IP address, VIP nodes 57 (including end nodes and routers) have a cache called "AMT (Address 58 Mapping Table)". The AMT consists of authentic entries, each of which 59 holds the relation between the VIP address and the IP address of a 60 mobile node. The AMT allows routing optimization for packets destined 61 to mobile nodes. It also provides fault tolerance of network 62 partitioning. 64 1.1. Assumptions 66 VIPv2 requires a mechanism for secret key distribution among nodes. 67 VIPv2 itself does not include any protocols for key distribution. It is 68 assumed that some key distribution mechanisms (including off-line 69 distribution) are available. 71 1.2. Terminology 73 This memo uses the following terms. 75 IP Address 77 The IP address of a mobile node specifies its current point of 78 attachment to the Internet. In other words, the IP address is the 79 "locator" of a mobile node. When a mobile node moves to another 80 subnet, it obtains an IP address by some methods such as DHCP[2]. 82 VIP Address 84 The VIP address is the "identifier" of a mobile node. It never 85 changes even if a mobile node moves in the Internet. The VIP address 86 has the same format as the IP address. TCP/UDP uses the VIP address 87 to specify the target node. The VIP address can be used as the 88 "default locator" of a mobile node. 90 Home Subnet 92 The subnet specified by the VIP address of a mobile node. Each 93 mobile node has its home subnet. The IP address of a mobile node 94 becomes equal to its VIP address in its home subnet. 96 Home Router 97 The router connected to the home subnet of a mobile node. Each 98 mobile node has its home router(s). The home router maintains the 99 relation between the VIP addresses and the IP addresses of mobile 100 nodes it manages. The home router also advertises routing 101 information for the VIP addresses of mobile nodes it manages. The 102 home router catches a packet destined to the VIP address of a mobile 103 node, resolves the destination VIP address into the destination IP 104 address, and then forwards the packet. 106 Address Resolution 108 Address resolution is a process to map a VIP address to an IP 109 address. 111 Address Mapping Table (AMT) 113 The AMT consists of authentic entries, each of which holds relation 114 between a VIP address and an IP address. Each node (including an end 115 node and a router) holds an AMT for address resolution. 117 Address Resolver 119 The address resolver is a node (including an end node and a router) 120 that executes address resolution. The home router of a mobile node 121 is an address resolver for the mobile node. A router becomes an 122 address resolver for a mobile node if it holds an AMT entry for the 123 mobile node. 125 2. Packet Format 127 2.1. Data Packet Header Format 129 Figure 1 depicts the header format of the VIPv2 data packet. First 20 130 octets are the basic IP header followed by the VIP header as an IP 131 option. In a VIPv2 packet, no other IP options can be included in the 132 IP header because the VIP header occupies the whole space (40 octets) 133 for IP options. 135 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3 136 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |Ver = 4|IHL=0xf| TOS | Total Length | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Identification |Flags| Fragment Offset | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | TTL | Protocol | Header Checksum | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Source VIP Address | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Destination IP Address | 147 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 148 |OptType = 0x8c | OptLen = 0x28 |ver = 2| rsvd | Flags | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Source IP Address | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Source Address Version | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Destination VIP Address | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Destination Address Version | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Resolver IP Address | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Holding Time | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Timestamp | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | | 165 + Authentication Data + 166 | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1. VIPv2 data packet header format 171 7 6 5 4 3 2 1 0 172 +---+---+---+---+---+---+---+---+ 173 |1/0| 0 | 0 |1/0| 0 |1/0|1/0|1/0| 174 +---+---+---+---+---+---+---+---+ 175 ^ ^ ^ ^ ^ 176 | | | | | 177 | | | | +-- don't cache 178 | | | +------ don't resolve 179 | | +---------- keyed MD5 included 180 | +------------------ control(1)/data(0) 181 +------------------------------ RSA digital signature appended 183 Figure 2. Flags 185 Source VIP Address 187 This field specifies the identifier (the VIP address) of the source 188 node. In IP, this field is used as the Source IP Address field. For 189 backward compatibility with IP, this field is used as the Source VIP 190 Address field in VIPv2. 192 Destination IP address 194 This field specifies the location of the destination node. This 195 field will be rewritten by address resolution. 197 Option Type (OptType) 199 This field specifies that this IP option is the VIP header. The 200 value is 0x8c (140), which means this option will be copied into 201 every fragment when fragmentation occurs. Currently, this value is 202 unofficial. 204 Option Length (OptLen) 206 This field specifies the length of the VIP header as an IP option. 207 The value is 0x28 (40 octets). 209 Version (ver) 211 This field specifies the VIP version. The current version is 2. 213 Flags 215 Figure 2 depicts the format of the Flags field. 217 don't cache 219 If this flag is on, nodes other than the home router of the source 220 node do not create an AMT entry for the source node. 222 don't resolve 224 If this flag is on, nodes other than the home router of the 225 destination node do not execute address resolution for the 226 destination node. 228 keyed MD5 included 230 If this flag is on, authentication data based on keyed MD5 is 231 included in this packet. 233 control/data 235 If this flag is on, this packet is the VIP control packet. If 236 this flag is off, this packet is a VIP data packet. 238 RSA digital signature appended 240 If both of this flag and the control flag are on, this control 241 packet includes authentication data based on RSA digital signature 242 in the data part. 244 Source IP Address 246 This field specifies the location of the source node. For 247 compatibility with IP, the Source IP Address field is placed in the 248 VIP header. 250 Source Address Version 252 This field specifies the version number of the relation between the 253 source VIP address and the source IP address. 255 Destination VIP address 257 This field specifies the identifier (the VIP address) of the 258 destination node. 260 Destination Address Version 262 This field specifies the version number of the relation between the 263 destination VIP address and the destination IP address. This field 264 will be rewritten by address resolution. 266 Resolver IP address 268 This field specifies the IP address of the node that executed address 269 resolution for this packet. This field will be rewritten by address 270 resolution. 272 Holding Time 274 When this packet causes creation or update of an AMT entry on a node, 275 this field specifies the time in second for which the node should 276 keep this AMT entry. 278 Timestamp 280 This field specifies the time at which the source node transmits this 281 packet. This field will be used to prevent "replay attack". 283 Authentication Data 285 The data for source node authentication. Keyed MD5 is used to 286 calculate this data. The source node shares a secret key with each 287 destination node. On the source node, the authentication data is 288 calculated as follows. MD5 is calculated over the following five 289 fields followed by the secret key: Source VIP Address, Source IP 290 Address, Source Address Version, Holding Time, and Timestamp. The 291 length of the Authentication Data is 8 octets due to the limit of IP 292 option length although MD5 generates a 16-octet message digest. The 293 first 8-octet and the last 8-octet of the message digest are xor'ed 294 to generate 8-octet data. 296 2.2. Control Packet Header Format 298 The VIPv2 control packet is used for AMT update, e.g., to notify the 299 current IP address to the home router. Figure 3 depicts the format of 300 the VIPv2 control packet. 302 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 |Ver = 4|IHL=0xf| TOS | Total Length | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Identification |Flags| Fragment Offset | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | TTL | Protocol | Header Checksum | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Source VIP address | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Destination IP address | 314 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 315 |OptType = 0x8c | OptLen = 0x28 |ver = 2| rsvd | Flags | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Source IP Address | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Source Address Version | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | VIP Address | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | IP Address | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Address Version | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Holding Time | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Timestamp | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | 332 + Authentication Data + 333 | | 334 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 335 | (Data Part of IP) | 336 | | 337 | Authentication Data | 338 | (RSA digital signature) | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 3. Control packet header format 343 The meanings of the following eight fields are the same as those of the 344 VIPv2 data packet header: Source VIP Address, Destination IP Address, 345 Option Type, Option Length, Version, Flags, Source IP Address, and 346 Source Address Version. 348 VIP Address 350 This field specifies the VIP address for AMT update. 352 IP Address 354 This field specifies the IP address corresponding to the VIP Address 355 field. 357 Address Version 359 This field specifies the version number of the relation between the 360 VIP Address field and the IP Address field. 362 Holding Time 364 When this packet causes creation or update of an AMT entry on a node, 365 this field specifies the time in second for which the node should 366 keep this AMT entry. 368 Timestamp 370 This field specifies the time at which the source node transmits this 371 packet. This field will be used to prevent "replay attack". 373 Authentication Data 375 the data for authentication of the VIP Address field. Keyed MD5 is 376 used to calculate this data. The source node shares a secret key 377 with each destination node. On the source node, the authentication 378 data is calculated as follows. MD5 is calculated over the following 379 five fields followed by the secret key: VIP Address, IP Address, 380 Address Version, Holding Time, and Timestamp. The length of the 381 Authentication Data is 8 octets due to the limit of IP option length 382 although MD5 generates a 16-octet message digest. The first 8-octet 383 and the last 8-octet of the message digest are xor'ed to generate 8- 384 octet data. 386 Authentication Data (RSA digital signature) 388 This field is in the data part of the IP packet, not in the IP 389 header. The source node may append this field to create or update 390 the AMT entry on intermediate routers. 392 3. AMT Entry Format 394 Since the AMT is node-local data, there is no standard format of the AMT 395 entry. Figure 4 depicts an example of an AMT entry format. The 396 meanings of the following six fields are obvious: VIP Address, IP 397 Address, Address Version, Holding Time, Timestamp, and Authentication 398 Data. 400 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3 401 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | VIP Address | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | IP Address | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Address Version | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Holding Time | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Timestamp | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Flags | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Timer | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 4. AMT entry format 420 Flags 422 invalid 424 If this flag is on, this AMT entry has invalid data. An invalid 425 AMT entry is used to detect a packet having obsolete mapping 426 between the destination VIP address and the destination IP 427 address. 429 home 431 If a node has an AMT entry in which this flag is on, this node is 432 connected to the home subnet of the mobile node specified by this 433 AMT entry. If this node is a router, it is one of home routers of 434 the mobile node. 436 local 438 If a node has an AMT entry in which this flag is on, this node is 439 connected to the subnet to which the mobile node specified by this 440 AMT entry is connected. 442 Timer 444 The value in this field is decremented every second. When the value 445 becomes zero, this entry is deleted. 447 4. Procedures on a Mobile Node 449 4.1. Procedures upon Connecting to a Subnet 451 When a mobile node moves to a subnet, it obtains an IP address in that 452 subnet by some methods such as DHCP. The mobile node transmits a VIPv2 453 control packet to its home router. 455 If a mobile node is connected to its home subnet, its IP address becomes 456 equal to its VIP address. The mobile node broadcasts a VIPv2 control 457 packet in the home subnet if the home subnet is a broadcast-type subnet 458 such as an Ethernet. 460 Each field of the control packet is set as follows: 462 Source VIP Address the VIP address of the mobile node. 464 Destination IP Address the IP address of the home router. The 465 VIP address of the mobile node can be used. 467 Flags "control", "don't cache", and "don't 468 resolve" flags are on. 470 Source IP Address the obtained IP address. 472 Source Address Version the address version of the current IP 473 address. 475 VIP Address the VIP address of the mobile node. 477 IP Address the obtained IP address. 479 Address Version the address version of the current IP 480 address. 482 Holding Time a certain value. 484 Timestamp the current time at which this packet is 485 created. 487 Authentication Data keyed MD5 calculated over the above five 488 fields followed by the shared key with 489 the home router. 491 The mobile node periodically transmits the control packet to its home 492 subnet while it is connected to the Internet. 494 4.2. Procedures upon Data Packet Transmission 496 When a node transmits a data packet, each field of the header is set as 497 follows: 499 Source VIP Address the VIP address of the node. 501 Destination IP Address if the node holds an AMT entry for the 502 target node, the IP address in the 503 entry is set. If not, the VIP address 504 of the target node is set. 506 Flags none of flags are usually set. 508 Source IP Address the current IP address of the node. 510 Source Address Version the address version of the node. 512 Destination VIP Address the VIP address of the target node. 514 Destination Address Version If the node holds an AMT entry for the 515 target node, the address version in the 516 entry is set. If not, zero is set. 518 Resolver IP Address If the node executes address 519 resolution, the IP address of the node 520 is set. If not, zero is set. 522 Holding Time a certain value 524 Timestamp the current time at which this packet 525 is created. 527 Authentication Data keyed MD5 calculated over the following 528 five fields followed by the shared key 529 with the target node: Source VIP 530 Address, Source IP Address, Source 531 Address Version, Holding Time, and 532 Timestamp. 534 4.3. Procedures upon Data Packet Reception 536 When a node receives a VIPv2 data packet, it compares its IP address 537 with the destination IP address in the packet header, and then compares 538 its VIP address with the destination VIP address in the packet header. 539 If both addresses are the same, the received packet is passed to the 540 upper layer. 542 At the same time, the node checks the Authentication Data field. If the 543 node has the shared key with the source node of the packet, it 544 calculates keyed MD5 in the same way as the source node. If the 545 calculation result is equal to the value in the Authentication Data 546 field, the node updates its AMT based on the information in the received 547 packet header as described below. 549 From Mobile Node Away from its Home 551 If the node does not have an AMT entry for the source node and the 552 source IP address and the source VIP address of the packet header are 553 different, then a new AMT entry for the source node is created. Each 554 field of the AMT entry is set as follows: 556 VIP Address the Source VIP Address field of the packet. 558 IP Address the Source IP Address field of the packet. 560 Address Version the Source Address Version field of the packet. 562 Holding Time the Holding Time field of the packet. 564 Timestamp the Timestamp field of the packet. 566 Timer the Timestamp field of the packet. 568 If the node has an AMT entry for the source node and the Version field 569 of the AMT entry is older than the Source Address Version field of the 570 packet header, then the AMT entry is updated by modifying all the fields 571 except the VIP address field. 573 If the node has an AMT entry for the source node with the same version 574 number and the Timestamp field of the AMT entry is older than the 575 Timestamp field of the packet header, then the AMT entry is updated by 576 modifying the Timestamp field and the Timer field. 578 If the node has an AMT entry for the source node with the same version 579 number and the same timestamp, then the Timer field of the AMT entry is 580 re-initialized with the value in the Holding Time field. 582 From Mobile Node in its Home 584 If the node has an AMT entry for the source node, the Version field of 585 the AMT entry is older than the Source Address Version field of the 586 packet header, and the Source VIP Address field and the Source IP 587 Address field of the packet header are the same, then the node set the 588 Invalid flag in the Flags field of the AMT entry, instead of deleting 589 the AMT entry. 591 5. Procedures on a Home Router 592 5.1. Procedures upon Control Packet Reception 594 When a home router receives a VIPv2 control packet, it examines whether 595 it is the home router of the source node of the packet, and whether the 596 authentication data is correct. If both checks succeed, the home router 597 updates its AMT as described below. 599 From Mobile Node Away from its Home 601 If the home router does not have an AMT entry for the source node, and 602 the source IP address and the source VIP address of the packet header 603 are different, then a new AMT entry for the source node is created. 604 Each field of the AMT entry is set as follows: 606 VIP Address the VIP Address field of the packet. 608 IP Address the IP Address field of the packet. 610 Address Version the Address Version field of the packet. 612 Holding Time the Holding Time field of the packet. 614 Timestamp the Timestamp field of the packet. 616 Timer the Timestamp field of the packet. 618 If the home router has an AMT entry for the source node and the Version 619 field of the AMT entry is older than the Source Address Version field of 620 the packet header, then the AMT entry is updated by modifying all the 621 fields except the VIP address field. The home router also transmits a 622 VIPv2 control packet to the subnet specified by the IP address field of 623 the old AMT entry. This control packet has the same VIPv2 header as the 624 received packet. 626 If the home router has an AMT entry for the source node with the same 627 version number and the Timestamp field of the AMT entry is older than 628 the Timestamp field of the packet header, then the AMT entry is updated 629 by modifying the Timestamp field and the Timer field. 631 If the home router has an AMT entry for the source node with the same 632 version number and the same timestamp, then the Timer field of the AMT 633 entry is re-initialized with the value in the Holding Time field. 635 In any case, when a home router receives a VIPv2 control packet from a 636 mobile node it manages, it broadcasts the received control packet in the 637 home subnet if the home subnet is a broadcast-type subnet such as an 638 Ethernet. 640 From Mobile Node in its Home 642 If the home router has an AMT entry for the source node, the Version 643 field of the AMT entry is older than the Source Address Version field of 644 the packet header, and the Source VIP Address field and the Source IP 645 Address field of the packet header are the same, then the home router 646 set the Invalid flag in the Flags field of the AMT entry, instead of 647 deleting the AMT entry. The home router also transmits a VIP control 648 packet to the subnet specified by the IP address field of the old AMT 649 entry. This control packet has the same VIP header as the received 650 packet. 652 5.2. Procedures on Data Packet Reception 654 The Destination IP Address field of the basic IP header contains the VIP 655 address of the destination node if the source node does not have an AMT 656 entry for the destination node. This packet reaches the home router of 657 the destination node because the home router advertises the routing 658 information for the destination node. 660 If the home router has an AMT entry for the destination node, it 661 executes address resolution and forwards the packet. In address 662 resolution, the following fields in the packet header are modified. 664 Destination IP Address the IP Address field of the AMT entry. 666 Destination Address Version the Address Version field of the AMT 667 entry. 669 If the packet is an IP packet, not a VIP packet, the home router convert 670 the IP packet into a VIP packet and forwards it. 672 6. Procedures on an Router in the Previous Subnet 674 When a mobile node leaves a subnet and enters a new subnet, the home 675 router of the mobile node may transmit a VIPv2 control packet to the 676 router in the previous subnet. This router updates its AMT if it has 677 the key used for the authentication data in the packet. 679 The router also broadcasts the received packet if the subnet is a 680 broadcast-type subnet such as an Ethernet. 682 7. Procedures on an Intermediate Router 684 7.1. Procedures upon Control Packet Forwarding 686 When a router forwards a VIPv2 control packet, if it has the key used 687 for the authentication data in the packet header, it updates its AMT. 689 The router can also use the RSA digital signature included in the data 690 part of the control packet to authenticate the mapping information in 691 the packet header. A public key is used to authenticate a digital 692 signature. Since distribution of public keys is easier than that of 693 secret keys, digital signature is useful to create AMT entries for 694 mobile nodes on intermediate routers for the sake of routing 695 optimization and fault tolerance of network partitioning. 697 7.2. Procedures upon Data Packet Forwarding 699 When a router forwards a VIPv2 data packet, it searches for an AMT entry 700 for the destination node. If it has a valid AMT entry and the Version 701 field of the AMT entry is newer than the Destination Address Version 702 field of the packet header, the router executes address resolution. 704 If the router has an invalid AMT entry and the Version field of the AMT 705 entry is equal to or newer than the Destination Address Version field of 706 the packet header, it modifies the packet header as follows and then 707 forwards it. 709 Destination IP Address the Destination VIP Address of the 710 header. 712 Destination Address Version 0 714 At the same time, if the router has the key used for the authentication 715 data calculation in the packet, it updates its AMT. 717 Author's Address 719 Fumio Teraoka 720 Sony Computer Science Laboratory Inc. 721 3-14-13 Higashigotanda, Shinagawa-ku, Tokyo 141, Japan. 722 Phone: +81-3-5448-4380 723 Email: tera@csl.sony.co.jp 725 References 727 [1] F. Teraoka, K. Uehara, H. Sunahara, and J. Murai. VIP: A Protocol 728 Providing Host Mobility. CACM, Vol. 37, No. 8, Aug. 1994. 730 [2] R. Droms. Dynamic Host Configuration Protocol. RFC 1541, October 731 1993.