idnits 2.17.00 (12 Aug 2021) /tmp/idnits44904/draft-leekj-nemo-ro-pd-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 (16 February 2004) is 6669 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: '4' is defined on line 290, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 293, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 296, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 300, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 307, but no explicit reference was found in the text == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '2') == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 == Outdated reference: draft-ietf-seamoby-mobility-terminology has been published as RFC 3753 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-mobility-terminology (ref. '4') -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-01) exists of draft-troan-dhcpv6-opt-prefix-delegation-00 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 == 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. '9') -- Possible downref: Normative reference to a draft: ref. '10' Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission 2 Internet Draft Kyeong-Jin Lee 3 Jae-Hoon Jeong 4 Jung-Soo Park 5 Hyoung-Jun Kim 6 ETRI 7 Expires: August 2004 16 February 2004 9 Route Optimization for Mobile Nodes in Mobile Network 10 based on Prefix Delegation 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 except that the right to 16 produce derivative works is not granted [1]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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 26 material 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 This document describes how to support Route Optimization for the 37 Mobile Nodes in IPv6 Mobile Network. The support is provided by 38 Prefix Delegation. Mobile Router gets a prefix from an access router 39 using Prefix Delegation protocol and advertises the delegated prefix 40 to its subnet. Each Mobile Nodes makes its care-of address from the 41 prefix and performs binding update. It allows the Mobile Nodes to 42 communicate with correspondent nodes directly, avoiding ingress 43 filtering. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [2]. 51 Table of Contents 53 1. Terminology and Abbreviation..................................2 54 2. Introduction..................................................2 55 3. Protocol Overview.............................................3 56 4. Neighbor Discovery extension : Delegated Prefix option format.6 57 5. Mobile IPv6 extension : Process of Delegated Prefix option....7 58 6. Handover Considerations.......................................7 59 7. Security Considerations.......................................7 60 8. Consideration for Optimization of DNS Name Resolution.........7 61 9. Applicability Statements......................................7 62 10. References....................................................8 63 11. Authors' Addresses............................................8 65 1. Terminology and Abbreviation 67 This document uses the terminology and abbreviation conformed to [1] 68 [2] and [3] on the assumption that the reader is familiar with Mobile 69 IPv6 and NEMO terminology. In addition, following terms are used: 71 Delegated Prefix (DP) 72 A prefix assigned to a site by a provider, from which the site 73 may derive link prefixes [3] 75 2. Introduction 77 NEMO Basic Support is to preserve session continuity using 78 bidirectional tunnel between Mobile Router (MR) and the MRÆs HA. The 79 support is reasonable for small-scale mobile network because MR MUST 80 encapsulate and decapsulate all packets for Mobile Network Nodes. 81 Specially, outbound packets MUST be tunneled in order to pass ingress 82 filtering. 84 The purpose of this document is to enable MNs behind the MR to 85 perform Mobile IPv6 Route Optimization. This can reduce the overhead 86 on MR because MR considers the packets of Local Fixed Nodes in the 87 bidirectional tunnel between MR and HA. 89 When MR detects its movement, it runs Prefix Delegation (PD) protocol 90 such as APD, RA-PD and DHCPv6 described in [5]-[7] respectively. If 91 MRs become placed in multiple levels, the mobile network has 92 hierarchical architecture. Most of the current PD protocols are 93 designed for leaf network. How to extend PD protocol for hierarchical 94 IPv6 network is outside the scope of this specification. For example, 95 HPD (Hierarchical APD) protocol described in [10] is an extension of 96 the APD protocol. 98 Even when every AR on visited network does not support PD, there 99 SHOULD be no problem in the communication between MN and CN. If this 100 mechanism is disabled, all the Mobile Network Nodes (MNNs) 101 communicate with CN by NEMO Basic Support. Therefore, it can provide 102 Route Optimization for mobile nodes within mobile network according 103 as the access network allows PD. 105 This specification defines a new Neighbor Discovery Protocol option 106 and modifies the operation of MR and MN to support route optimization. 107 Fixed router in mobile network is not considered in this 108 specification. 110 3. Protocol Overview 112 This document assumes that all AR and MR support PD. Otherwise, only 113 NEMO Basic Support [8] is provided to preserve session continuity and 114 Route Optimization is disabled. 116 Figure 1 shows a topology before two MRs move from home link to 117 foreign link. When the MR1 and MR2 are at home link, each MR uses 118 1:1:: and 2:1:: respectively as its own mobile network prefix. 120 +---+ 121 |CN | 122 +-+-+ 123 | 124 +------+ +--+-----+ +------+ 125 |HA-MR1|-----------|Internet|----------------|HA-MR2| 126 +---+--+ +--+-----+ +----+-+ 127 |1:: | 2:: | 128 +-+-+1 +--+-+ +-+-+3 129 |MR1| | AR | |MR2| 130 +-+-+2 +--+-+ +-+-+4 131 |1:1:: | 3:: 2:1:: | 132 --+---+--+------+- ----+--- ---+---+--+-- 133 | | | | | 134 +-+-+5 +-+-+6 +-+-+7 +-+-+8 +-+-+9 135 |LMN| |VMN| |LFN| |LMN| |VMN| 136 +---+ +---+ +---+ +---+ +---+ 138 Figure 1. Mobile router at home link 140 Figure 2 shows a topology after two MRs move from home link to 141 foreign link and each MR performs PD. First, MR1 detects movement and 142 gets a prefix (3:1::) from AR. MR1 advertises the DP to its subnet by 143 sending RA message with Delegated Prefix option. And then, MR2 moves 144 to MR1's network. MR2 gets prefix (3:1:1::) from MR1 and advertises 145 the prefix to its subnet. 147 When each MN receives RA message with Delegated Prefix option, it 148 processes the DP option preferentially: make CoA from the prefix and 149 performs binding updates to HA and CN. In figure 2, CoA1 is used as a 150 primary CoA, which is made from DP. This process is transparent to 151 LFNs. 153 +---+ 154 |CN | 155 +-+-+ 156 | 157 +------+ +--+-----+ +------+ 158 |HA-MR1|-----------|Internet|----------------|HA-MR2| 159 +---+--+ +--+-----+ +----+-+ 160 |1:: | 2:: | 161 +--+-+ 162 | AR | 163 +--+-+ 164 | 3:: 165 --+----+------ 166 | 167 +-+-+ HoA 1::1, CoA 3::1 168 |MR1| Delegated Prefix(DP) = 3:1:: 169 +-+-+ Mobile Network Prefix(MNP) = 1:1:: 170 | 171 --+---+--+------+--------+------ 172 | | | | 173 +-+-+ +-+-+ +-+-+ +-+-+ HoA 2::3 174 |LMN| |VMN| |LFN| |MR2| CoA1 3:1::3 175 +---+ +---+ +---+ +-+-+ CoA2 1:1::3 176 CoA1 3:1::5 3:1::6 | DP = 3:1:1:: 177 CoA2 1:1::6 ---+---+--+-- MNP = 2:1:: 178 | | 179 +-+-+ +-+-+ 180 |LMN| |VMN| 181 +-+-+ +-+-+ 182 CoA1 3:1:1::8 3:1:1::9 183 CoA2 2:1::9 185 Figure 2. Prefix Delegation for Route Optimization 187 After the PD, the routing table of routers is updated. It is possible 188 because each router has information about delegated prefix. 190 4. Neighbor Discovery extension : Delegated Prefix option format 192 This specification defines a new option, the Delegated Prefix option, 193 for the Neighbor Discovery protocol of IPv6. The option format is 194 shown in Figure 2. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type | Length | Prefix Length |L|A| Reserved1 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Valid Lifetime | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Preferred Lifetime | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Reserved2 | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 + + 209 | | 210 + Prefix + 211 | | 212 + + 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 2. Delegated Prefix Option Format for Route Optimization 217 Fields: 219 Type XXX [TBD: IANA] 221 Prefix Delegated Prefix. The Prefix Length field contains 222 the number of valid leading bits in the prefix. 223 The bits in the prefix after the prefix length 224 are reserved and MUST be initialized to zero by 225 the sender and ignored by the receiver 227 The Delegated Prefix option provides mobile nodes with on-link prefix 228 of access network and prefix for address autoconfiguration of CoA. 229 The Delegated Prefix option appears in Router Advertisement packets 230 and MUST be silently ignored for other messages. 232 5. Mobile IPv6 extension : Process of Delegated Prefix option 234 MN scans all options in received router advertisement message. To 235 initiate Route Optimization MN operation MUST be extended as follows: 237 (1)Process the new RA option, Delegated Prefix option: MN forms CoA 238 using the prefix. 239 (2)Use the CoA as primary CoA. 241 MN performs registration procedure according to the Mobile IPv6 242 protocol. Even if LMN is on home link, it SHOULD make new CoA using 243 the DP and SHOULD perform binding updates to HA and CN. In this case, 244 deregistration SHOULD NOT be performed. 246 There is no change of HA and CN operations. 248 6. Handover Considerations 250 When a MR moves into another AR and detects movement, it SHOULD NOT 251 return prefix delegated from the old AR immediately. It takes some 252 time to find out whether the new AR supports PD or not. Moreover, MR 253 can fail in PD for several reasons. Therefore, some considerations 254 are needed for smooth handover. 256 7. Security Considerations 258 Because the mechanism described in this document needs to exchange PD 259 message between a MR and its AR, AAA MAY be used to authenticate MR. 261 8. Consideration for Optimization of DNS Name Resolution 263 The optimization of DNS name resolution is possible if mobile router 264 announces the address of local recursive DNS server as well as prefix 265 information through RA message. The DNS server can exist either 266 within mobile network or within access network. The address of 267 recursive DNS server is delivered to mobile nodes through Recursive 268 DNS Server option, one of RA options [10]. 270 9. Applicability Statements 272 Proposed mechanism in this draft is applicable to large, hierarchical 273 and stable mobile network such as train or airplane because it takes 274 some time to configure and update new CoA by prefix delegation 275 protocol. Those mobile networks do not change its topology frequently 276 so it reduces time to be consumed for prefix delegation whenever the 277 topology changes in the mobile network. 279 10. References 281 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP9, 282 RFC 2026, October 1996. 284 [2] Thierry Ernst, "Network Mobility Support Terminology", draft- 285 ietf-nemo-terminology-00.txt, May 2003. 287 [3] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", 288 draft-ietf-mobileip-ipv6-24.txt, June 2003. 290 [4] J. Manner and M. Kojo, "Mobility Related Terminology", draft- 291 ietf-seamoby-mobility-terminology-05.txt, Nov 2003. 293 [5] Nathan Lutchansky, "IPv6 Router Advertisement Prefix Delegation 294 Option", draft-lutchann-ipv6-delegate-option-00.txt, Aug 2002. 296 [6] B. Haberman, "Automatic Prefix Delegation Protocol for Internet 297 Protocol Version 6 (IPv6)", draft-haberman-ipngwg-auto-prefix- 298 02.txt, Aug 2002. 300 [7] O. Troan and R. Droms, "IPv6 Prefix Options for DHCPv6", draft- 301 troan-dhcpv6-opt-prefix-delegation-00.txt, Aug 2002. 303 [8] Vijay Devarapalli, Ryuji wakikawa, Alexandru Petrescu and Pascal 304 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 305 draft-ietf-nemo-basic-support-02.txt, Dec 2003. 307 [9] Jaehoon Jeong, Soohong D. Park, Luc Beloeil and Syam Madanapalli, 308 "IPv6 DNS Discovery based on Router Advertisement", draft-jeong- 309 dnsop-ipv6-dns-discovery-01.txt, Feb 2004. 311 [10] Byung-Yeob Kim, Kyeong-Jin Lee, Jung-Soo Park and Hyoung-Jun Kim, 312 "Hierarchical Prefix Delegation Protocol for Internet Protocol 313 Version 6(IPv6)", draft-bykim-ipv6-hpd-01.txt, Feb 2004. 315 11. Authors' Addresses 317 Kyeong-Jin Lee 318 ETRI / PEC 319 161 Gajong-Dong, Yusong-Gu 320 Daejon 305-350 321 Korea 322 Phone: +82 42 860 6484 323 EMail: leekj@etri.re.kr 325 Jae-Hoon Jeong 326 ETRI / PEC 327 161 Gajong-Dong, Yusong-Gu 328 Daejon 305-350 329 Korea 331 Phone: +82 42 860 1664 332 EMail: paul@etri.re.kr 334 Jung-Soo Park 335 ETRI / PEC 336 161 Gajong-Dong, Yusong-Gu 337 Daejon 305-350 338 Korea 340 Phone: +82 42 860 6514 341 EMail: pjs@etri.re.kr 343 Hyoung-Jun Kim 344 ETRI / PEC 345 161 Gajong-Dong, Yusong-Gu 346 Daejon 305-350 347 Korea 349 Phone: +82 42 860 6576 350 EMail: khj@etri.re.kr