idnits 2.17.00 (12 Aug 2021) /tmp/idnits48399/draft-jeong-nemo-ro-ndproxy-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: ---------------------------------------------------------------------------- == 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 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 (14 February 2004) is 6671 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) == Unused Reference: '5' is defined on line 551, but no explicit reference was found in the text == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 ** Obsolete normative reference: RFC 2461 (ref. '4') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '5') (Obsoleted by RFC 4862) -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '7') == Outdated reference: draft-jeong-dnsop-ipv6-dns-discovery has been published as RFC 5006 ** Downref: Normative reference to an Experimental draft: draft-jeong-dnsop-ipv6-dns-discovery (ref. '8') == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-03 == Outdated reference: draft-ietf-send-ndopt has been published as RFC 3971 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft 3 Jaehoon Paul Jeong 4 Kyeongjin Lee 5 Jungsoo Park 6 Hyoungjun Kim 7 draft-jeong-nemo-ro-ndproxy-02.txt ETRI 8 Expires: August 2004 14 February 2004 10 ND-Proxy based Route and DNS Optimizations for 11 Mobile Nodes in Mobile Network 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 except that the right to 17 produce derivative works is not granted [1]. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document specifies a mechanism for enabling mobile nodes in IPv6 38 mobile network to perform route and DNS optimizations. The route 39 optimization is possible because mobile router relays the prefix of 40 its care-of address to its mobile nodes by playing the role of ND- 41 proxy. Through binding updates associated with the network prefix of 42 an access network, the mobile nodes can perform route optimization. 43 In addition, this document explains how mobile nodes can optimize its 44 DNS name resolution through RA-based DNS discovery. By announcing 45 the address of local recursive DNS server, mobile router allows 46 mobile nodes using the DNS server to optimize their DNS name 47 resolutions without additional overhead of finding DNS server. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [2]. 55 Table of Contents 57 1. Terminology...................................................2 58 2. Introduction..................................................3 59 3. Overview......................................................4 60 4. Neighbor Discovery extension..................................5 61 4.1 RO Prefix Information option format.......................5 62 4.2 Neighbor Solicitation (NS) message format.................6 63 4.3 DNS Server option format..................................7 64 5. Mobile Router.................................................8 65 5.1 Process of RO Prefix Information option...................8 66 5.2 Process of DNS Server option..............................9 67 5.3 Delivery of Data Packets..................................9 68 5.4 Movement of Mobile Router.................................9 69 6. Mobile Node..................................................10 70 6.1 Procedure of Route Optimization..........................10 71 6.1.1 Generation of a new CoA............................10 72 6.1.2 DAD for the new CoA................................10 73 6.1.3 Return Routability and Binding Update..............11 74 6.2 Procedure of DNS Optimization............................11 75 7. Security Considerations......................................11 76 8. Copyright....................................................11 77 9. Normative References.........................................12 78 10. Informative References......................................12 79 11. Acknowledgements............................................13 80 12. Authors' Addresses..........................................13 82 1. Terminology 84 This document uses the terminology described in [3]-[8]. Especially, 85 four important terms are defined as follows [6][8]: 87 Multilink Subnet (MS) 89 A collection of independent links, connected by routers, but 90 sharing a common subnet prefix. 92 ND-Proxy 94 A router proxying and relaying for all nodes on its router-mode 95 interfaces except proxy-mode interfaces among its network 96 interfaces. 98 Multilink-Subnet Router (MSR) 100 A router which has interfaces attached to different links in a 101 MS, and which plays the role of ND-Proxy. 103 Recursive DNS Server (RDNSS) 105 A Recursive DNS Server is a name server that offers the 106 recursive service of DNS name resolution. 108 2. Introduction 110 Recently, the demand and necessity of network mobility (NEMO) [3] is 111 increasing along with those of host mobility based on Mobile IPv6 112 (MIPv6) [9]. The purpose of network mobility is to guarantee the 113 continuity of the sessions of fixed nodes or mobile nodes (MN) within 114 mobile networks, such as car, bus, subway train, airplane and 115 submarine. The current solution is based on bi-directional tunnel 116 between home agent (HA) and mobile router (MR) [3]. The basic 117 support protocol of NEMO enables mobile network node (MNN) [7] and 118 correspondent node (CN) to communicate through the bi-directional 119 tunnel. Data exchange between MNN and CN is performed not via 120 optimal routing path, but via the non-optimal path including bi- 121 directional tunnel. MR's HA intercepts all of packets destined to 122 the MNNs and tunnels them to the MR. Also, the MNNs' outbound 123 packets are tunneled in order to pass ingress filtering [3][9]. This 124 mechanism is very simple but it gives up a powerful feature of MIPv6, 125 route optimization (RO) without ingress filtering. In addition, when 126 the mobile network has multiple nested MRs, packet delay between MNN 127 and CN becomes longer because of dog-legged routing and also packet 128 size becomes bigger due to extra IPv6 header attached to packet per 129 level of nesting [10]. 131 When we think over the applicability of NEMO in our daily life, we 132 can forecast that network mobility service will be provided in 133 vehicles, such as bus, subway train and airplane, because most 134 passengers in such vehicles will have hand-held PC or PDA as MN 135 rather than fixed node in near future. Therefore, it is necessary to 136 provide route optimization for such MNs. This document describes a 137 way of optimizing the routes between MNs and CNs, independently of 138 the level of nesting and without the extra IPv6 header. The route 139 optimization mechanism is based on the proxying function of MR, which 140 informs MNs within mobile network of the access network prefix to 141 make a care-of address (CoA) passing ingress filtering, and also 142 relays packets between access router and MN. This proxying for RO is 143 performed through IPv6 Neighbor Discovery (ND), which is called ND- 144 Proxy. 146 3. Overview 148 +---+ ******************* +---+ 149 |CN1+---* Internet *---+CN2| 150 +---+ ******************* +---+ 151 | 152 | 153 +-+-+ 154 |AR1| 155 RA(AR1_P)| +-+-+ 156 V | 157 ----------+---------------+---------------+----------- Link1 158 |Proxy-mode |Proxy-mode 159 +-+-+ +------+ +-+-+ +------+ 160 |MR1+--+RDNSS1| |MR2+--+RDNSS2| 161 RA(AR1_P)| +-+-+ +------+ RA(AR1_P)| +-+-+ +------+ 162 V |Router-mode V |Router-mode 163 ---+-----+-----+--- Link2 ---+------+-----+--- Link3 164 | | | Proxy-mode| 165 +-+-+ +-+-+ +-+-+ +-+-+ 166 |MN1| |MN2| |MN3| |MR3| 167 +---+ +---+ +---+ +-+-+ | RA(AR1_P) 168 Router-mode| V 169 ---+-----+-----+--- Link4 170 | | 171 +-+-+ +-+-+ 172 |MN4| |MN5| 173 +---+ +---+ 175 Figure 1. Multilink Subnet for Route Optimization 177 The route optimization is possible by MR's performing ND-Proxy, which 178 makes a CoA with the prefix advertised by access router and relays 179 the prefix of access network into the whole mobile network. Each MN 180 can make its new CoA with router advertisement message including 181 access network prefix and perform the return routability and binding 182 update procedure. As ND-Proxy, the MR performs neighbor discovery 183 for the sake of the MNs within its mobile network. Like this, 184 through MR that performs ND-Proxy, access network and mobile network 185 are configured into a multilink subnet. Figure 1 shows an example of 186 a multilink subnet comprised of four links from Link1 to Link4. Two 187 MRs, MR1 and MR2, receive the prefix information of access network 188 (AR1_P) that was sent by an access router, AR1 as proxy-mode and 189 relay it to their subnet link as router-mode [6]. Let's assume that 190 the MNs, MN1 and MN2, move into the mobile network managed by MR1 191 like Figure 1. Also, let's assume that these visiting mobile nodes 192 (VMN) communicate with the correspondent nodes, CN1 and CN2, 193 respectively. If these visiting mobiles can get the prefix of access 194 network and make their new CoA, through the binding update with their 195 correspondent node, they can communicate each other via an optimized 196 path. This dissemination of access network's prefix is performed by 197 MR which becomes attached to a foreign access network, not its home 198 network. Likewise, MN3 can optimize the route through MR2. MN4 and 199 MN5 can perform route optimization through MR2 and MR3, too. 201 The optimization of DNS name resolution is possible by MR's 202 announcing the address of local recursive DNS server as well as the 203 prefix information of access network. In Figure 1, by DNS Server 204 option included in RA message, MR1 announces the address of Recursive 205 DNS Server, RDNSS1, within its mobile network to its router-mode link, 206 Link2. Therefore, MNs within Link2, MN1 and MN2, can optimize their 207 DNS name resolution by using local DNS server, RDNSS1. 209 4. Neighbor Discovery extension 211 In order to support the route optimization, ND implementation in MR 212 and MN must be extended to process the prefix information option for 213 RO and that in Local Fixed Node (LFN) within mobile network, which 214 has no mechanism for MIPv6, need no change. 216 4.1 RO Prefix Information option format 218 The mechanism of this document needs a new O (Route-optimization) 219 flag within prefix information option for route optimization [4]. 220 When this flag is set on, it indicates that the prefix included in 221 the option can be used by MNs within a mobile network for route 222 optimization. Figure 2 shows the format of the modified prefix 223 information option, RO Prefix Information option, which is included 224 in RA message. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type | Length | Prefix Length |L|A|O|Reserved1| 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Valid Lifetime | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Preferred Lifetime | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Reserved2 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 + + 239 | | 240 + Prefix + 241 | | 242 + + 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 2. Prefix Information Option Format for Route Optimization 248 Field: 250 O 1-bit route-optimization flag. When set indicates 251 that this prefix can be used for the route 252 optimization of MNs within a mobile network. 254 The RO Prefix Information option provides an MN with the network 255 prefix of access network and allows it to autoconfigure its new CoA 256 through stateless address autoconfiguration and to perform binding 257 update. The Prefix Information option appears in RA message and MUST 258 be silently ignored for other messages. L (On-link) flag MAY be 259 either 0 or 1. Namely, this route optimization can be either on-link 260 or off-link model [6]. A (Autonomous address-configuration) flag 261 MUST be set on, indicating IPv6 stateless address autoconfiguration. 263 4.2 Neighbor Solicitation (NS) message format 265 NS message MUST be extended for Duplicate Address Detection (DAD) for 266 the address based on RO prefix to be performed in the whole mobile 267 network, not just within a link. Therefore, there is a need to 268 discriminate between the normal NS message and extended NS message 269 for route optimization [4]. Figure 3 shows the format of the 270 modified NS message. 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type | Code | Checksum | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 |M| Reserved | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | | 280 + + 281 | | 282 + Target IPv6 Address + 283 | | 284 + + 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Options ... 288 +-+-+-+-+-+-+-+-+-+-+-+- 289 Figure 3. Extended Neighbor Solicitation Message Format 291 Fields: 293 M 1-bit multi-hop flag. When set indicates 294 that this NS message SHOULD be relayed to the other 295 links of a multilink subnet. 297 Target IPv6 Address 298 The IPv6 address of the target of the solicitation, 299 e.g., CoA. It MUST NOT be a multicast address. 301 4.3 DNS Server option format 303 DNS Server option contains the IPv6 address of the recursive DNS 304 server. When advertising more than one DNS Server option, an RA 305 message includes as many DNS Server options as DNS servers. Figure 4 306 shows the format of DNS Server option [8]. 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type | Length | Pref | Reserved | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Lifetime | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | | 316 + + 317 | | 318 + IPv6 Address of DNS Server + 319 | | 320 + + 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 4. DNS Server Option Format 326 Fields: 328 Type 8-bit identifier of the option type (TBD: IANA) 330 Option Name Type 332 DNS Server (TBD) 334 Length 8-bit unsigned integer. The length of the 335 option (including the type and length fields) 336 in units of 8 octets SHOULD be 0x03 (3 x 8 = 24 337 octets). 339 Pref The preference of a DNS server. A 4-bit unsigned 340 integer. A decimal value of 15 indicates the 341 highest preference. A decimal value of zero 342 means unspecified. The field can be used for 343 load balancing of DNS queries with multiple 344 RDNSSes according to local policy. 346 Lifetime 32-bit unsigned integer. The maximum time, in 347 seconds, over which this DNS server is used for 348 name resolution. MNs should contact the 349 source of this information, MR, before 350 expiry of this time interval. A value of all one 351 bits (0xffffffff) represents infinity. A value 352 of zero means that the DNS server must not be 353 used any more. 355 IPv6 Address of DNS Server 356 Recursive DNS Server's address for DNS name 357 resolution. 359 5. Mobile Router 361 MR MUST process Prefix Information option for Route Optimization and 362 DNS Server option for DNS Optimization, which may be included in RA 363 message. 365 5.1 Process of RO Prefix Information option 367 Only if the prefix announced by an access router is different from 368 the prefix of an MR's Home Address (HoA), the MR MUST perform the 369 role of ND-Proxy and relay the prefix information. Before MR 370 advertises the prefix information through Router Advertisement (RA) 371 message, it MUST set O flag indicating that this prefix can be used 372 for route optimization of MNs, which are either local mobile nodes 373 (LMN) or VMNs within the mobile network. 375 If an MN within a mobile network receives the new prefix information 376 option through RA message and can recognize this option, it MAY 377 prefer RO prefix information option to normal prefix information 378 option that contains the mobile network prefix assigned by the MR's 379 home network. By performing binding update with the prefix of the 380 access network, the MN can optimize the routes between its 381 correspondent nodes and itself. 383 ND-Proxy MUST join the solicited-node multicast addresses that 384 correspond to the IPv6 addresses assigned to MNs for which it is 385 proxying for processing ND messages related to the MNs [4]. 387 5.2 Process of DNS Server option 389 If MR has its own local RDNSS like MR1 and MR2 in Figure 1, it SHOULD 390 announce the address of RDNSS to its router-mode link(s). 392 If MR receives DNS Server option from its proxy-mode link(s), it 393 SHOULD relay the option to its router-mode link(s) through its RA 394 message. In the case where MR has its own local RDNSS, it announces 395 the DNS Server option of its RDNSS with higher precedence than those 396 of other RDNSSes. 398 5.3 Delivery of Data Packets 400 After an MN gets a new CoA within a mobile network and performs 401 binding update associated with the address, the data packets of 402 correspondent node toward the MN can be delivered to the access 403 network to which the mobile network containing the MN is attached, 404 via optimal path between the mobile and correspondent nodes. 406 When the access router of the access network receives the data 407 packets toward an MN and there is no neighbor information for the MN, 408 it multicasts normal Neighbor Solicitation (NS) message to the 409 solicited-node multicast address of the destination IPv6 address in 410 order to find out the link-layer address of the destination MN. The 411 MR, knowing the link-layer address of the target, responds to the NS 412 message by returning its own link-layer address in a unicast Neighbor 413 Advertisement (NA) message as ND-Proxy, which knows the IPv6 414 addresses and link-layer addresses of MNs within its mobile network 415 while forwarding their data packets along with neighbor discovery 416 related to each destination node. 418 When the access router knows the link-layer address of next-hop 419 toward the destination MN, it forwards the IPv6 data packets to the 420 MR corresponding to the link-layer address. The packets are relayed 421 to next-hop toward the destination node by MR until the packets 422 arrive at the destination. Like this, in the case where the mobile 423 network where the destination node is placed is multi-level, the 424 packets may be relayed to the destination node by more than one MR 425 according to the route information in each MR's destination and 426 neighbor caches. 428 5.4 Movement of Mobile Router 429 When an MR moves into another access network and detects its movement 430 by movement detection algorithm [9], it performs binding update with 431 its HA with a new CoA based on the new access network prefix, and 432 then relays the prefix for RO into its other router-mode interfaces. 433 This allows the MRs and nodes to perform route optimization based on 434 the new access network prefix. When the MR returns to its home 435 network, it deregisters with its HA and advertises RA message that 436 contains RO Prefix Information option for the previous access network 437 prefix with Valid Lifetime and Preferred Lifetime set to zeroes and O 438 flag set on, and also Prefix Information option for MR's mobile 439 network prefix. The RO Prefix Information option SHOULD be 440 advertised at least three times. This RA message allows the MRs and 441 MNs below the MR explicitly to release their current CoA and to use 442 the MR's mobile network prefix in order to configure their addresses 443 according to MIPv6 protocol [9]. 445 6. Mobile Node 447 MN MUST process Prefix Information option for RO and DNS Server 448 option for DNS Optimization, which are included in RA message. 450 6.1 Procedure of Route Optimization 452 For RO, MN generates a new CoA based on the access network prefix and 453 performs binding update for the CoA. 455 6.1.1 Generation of a new CoA 457 Whenever an MN receives RA message containing RO prefix information 458 option that includes a new network prefix of access network, it makes 459 a new CoA. 461 6.1.2 DAD for the new CoA 463 The MN performs DAD for the new CoA through the extended NS message. 464 The NS message of DAD for the new address is disseminated by MRs, 465 acting as ND-Proxy, in the entire mobile network where the MN is 466 placed [6]. Each MR memorizes the DAD for returning NA message to 467 the originator or relayer of the extended NS message for a while. 469 If there is no NA returned after DAD timeout, the MN configures the 470 address as its new CoA in its network interface. 472 Therefore, the DAD for the link-local addresses and global addresses 473 based on mobile network prefix assigned by home network is performed 474 through normal NS message only within a link and the DAD for the 475 global addresses based on access network prefix is performed through 476 extended NS message within a multilink subnet, which is relayed by 477 ND-Proxies. 479 6.1.3 Return Routability and Binding Update 481 After configuring the new CoA, the MN performs the return routability 482 and binding update procedure of MIPv6 [9]. If the MN is VMN for the 483 mobile network where it is present, or as LMN, moves into another 484 link of the mobile network to which its home link belongs, it SHOULD 485 perform binding updates with both its HA and CNs. 487 6.2 Procedure of DNS Optimization 489 The optimization of DNS name resolution is possible by MR's 490 announcing the address of local RDNSS along with RO prefix 491 information through RA message like in Section 5.2 [8]. The DNS 492 server can exist either within mobile network or within access 493 network. The address of RDNSS is delivered to MNs through DNS Server 494 option, one of RA options. Especially, VMNs can optimize their DNS 495 name resolutions effectively by using a local RDNSS. 497 7. Security Considerations 499 The route optimization and DNS optimization in this document does not 500 add any other security problems to the NEMO, MIPv6, or ND protocol. 501 Security issues regarding the ND protocol are being discussed in IETF 502 SEND (Securing Neighbor Discovery) working group [11]. 504 8. Copyright 506 The following copyright notice is copied from RFC 2026 [Bradner, 507 1996], Section 10.4, and describes the applicable copyright for this 508 document. 510 Copyright (C) The Internet Society July 12, 2001. All Rights 511 Reserved. 513 This document and translations of it may be copied and furnished to 514 others, and derivative works that comment on or otherwise explain it 515 or assist in its implementation may be prepared, copied, published 516 and distributed, in whole or in part, without restriction of any 517 kind, provided that the above copyright notice and this paragraph 518 are included on all such copies and derivative works. However, this 519 document itself may not be modified in any way, such as by removing 520 the copyright notice or references to the Internet Society or other 521 Internet organizations, except as needed for the purpose of 522 developing Internet standards in which case the procedures for 523 copyrights defined in the Internet Standards process must be 524 followed, or as required to translate it into languages other than 525 English. 527 The limited permissions granted above are perpetual and will not be 528 revoked by the Internet Society or its successors or assignees. 530 This document and the information contained herein is provided on an 531 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 532 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 533 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 534 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 535 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 537 9. Normative References 539 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 540 9, RFC 2026, October 1996. 542 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 543 Levels", BCP 14, RFC 2119, March 1997. 545 [3] Vijay Devarapalli et al., "Nemo Basic Support Protocol", draft- 546 ietf-nemo-basic-support-02.txt, December 2003. 548 [4] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for 549 IP version 6", RFC 2461, December 1998. 551 [5] S. Thomson and T. Narten, "IPv6 Stateless Address 552 Autoconfiguration", RFC 2462, December 1998. 554 [6] Dave Thaler and Chistian Huitema, "Multi-link Subnet Support in 555 IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, June 2002. 557 [7] T. Ernst and H.-Y. Lach, "Network Mobility Support Terminology", 558 draft-ietf-nemo-terminology-00.txt, May 2003. 560 [8] Jaehoon Paul Jeong et al., "IPv6 DNS Discovery based on Router 561 Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-01.txt, 562 February 2004. 564 10. Informative References 566 [9] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", 567 draft-ietf-mobileip-ipv6-24.txt, June 2003. 569 [10] Pascal Thubert and Marco Molteni, "IPv6 Reverse Routing Header 570 and its application to Mobile Networks", draft-thubert-nemo- 571 reverse-routing-header-03.txt, October 2003. 573 [11] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft-ietf- 574 send-ndopt-03.txt, January 2004. 576 11. Acknowledgements 578 The authors would like to acknowledge the previous contribution of 579 Dave Thaler and Christian Huitema for ND-Proxy. 581 12. Authors' Addresses 583 Jaehoon Paul Jeong 584 ETRI / PEC 585 161 Gajeong-dong, Yuseong-gu 586 Daejon 305-350 587 Korea 589 Phone: +82 42 860 1664 590 EMail: paul@etri.re.kr 592 Kyeongjin Lee 593 ETRI / PEC 594 161 Gajeong-dong, Yuseong-gu 595 Daejon 305-350 596 Korea 598 Phone: +82 42 860 6484 599 EMail: leekj@etri.re.kr 601 Jungsoo Park 602 ETRI / PEC 603 161 Gajeong-dong, Yuseong-gu 604 Daejon 305-350 605 Korea 607 Phone: +82 42 860 6514 608 EMail: pjs@etri.re.kr 610 Hyoungjun Kim 611 ETRI / PEC 612 161 Gajeong-dong, Yuseong-gu 613 Daejon 305-350 614 Korea 616 Phone: +82 42 860 6576 617 EMail: khj@etri.re.kr