idnits 2.17.1 draft-lee-v6ops-natpt-mobility-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 373. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 1) being 62 lines 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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 2005) is 6890 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: '0' is mentioned on line 296, but not defined ** Obsolete normative reference: RFC 2766 (ref. '1') (Obsoleted by RFC 4966) ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-3gpp-cases (ref. '2') == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-3gpp-analysis-03 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-3gpp-analysis (ref. '3') ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3344 (ref. '5') (Obsoleted by RFC 5944) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Joo-Chul Lee 3 Expires: December 2005 Myung-Ki Shin 4 ETRI 5 June 2005 7 Considerations for Mobility Support in NAT-PT 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other docu- 24 ments at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in pro- 26 gress." 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 This Internet-Draft will expire on December, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The document specifies considerations for mobility support in NAT- 43 PT (RFC-2766) [1]. 45 1. Introduction 47 NAT-PT (RFC-2766) enables end-nodes in IPv6 realm to communicate 48 with end-nodes in IPv4 realm and vice versa. RFC-2766 [1] needs 49 some fixes and/or applicability statements. Among them, there 50 exists considerations in NAT-PT [1] when IPv6 end-nodes move. 3GPP 51 drafts [2, 3] mention that there is a need for transltors, such as 52 NAT-PT, but in this case, current RFC-2766 [1] does not support 53 IPv6 mobile nodes. The document specifies considerations for 54 mobility support in NAT-PT (RFC-2766)[1]. 56 2. Issues with mobility support in NAT-PT 58 2.1 Movement of end-nodes in IPv6 realm (IPv6-MNs) 60 When IPv6 end-nodes move, there are issues should be considered in 61 RFC-2766. Basically, since mobile IPv6 (MIPv6) [4] provides route 62 optimization, NAT-PT box must update its associated address mapping 63 entries. As well, NAT-PT box needs appropriate handling of con- 64 trols such as RR (Return Routability), BU (Binding Update), etc. 66 +---------+ 67 +------------------------>| IPv4 CN | 68 | +---------+ 69 V IPv4 domain 70 +----------+ 71 /--------------| NAT-PT |-----------\ 72 / +----------+ \ 73 | / | | 74 | /-----/ | | 75 | / | | 76 | : +-------+ | 77 | : | R1 | | 78 | / +-------+ | 79 | +-------+ / \ | 80 | | HA | / +-------+ | 81 | +-------+ : | R2 | | 82 | | : +-------+ | 83 | | | | 84 | +-------+ | | 85 | |IPv6 MN|- - - + ------+---+- | 86 | +-------+ | | | 87 | . +-------+ | 88 | +- - - - -> |IPv6 MN| | 89 | Movement +-------+ | 90 \ / 91 \-------------------------------------/ 92 IPv6 realm 94 2.2 Movement of end-nodes in IPv4 realm (IPv4-MNs) 96 Obviously, there is no issue when IPv4 end-nodes move, since mobile 97 IPv4 (MIPv4) ][5] uses tunneling. 99 3. Mobility support in NAT-PT box 101 This section describes the case that an IPv6-MN moves from home 102 network to other network in the same IPv6 island. 104 Main consideration is that NAT-PT box does all of MIPv6 105 functionalities on behalf of IPv4-CNs. Following subsections show 106 how NAT-PT box works in this situation. 108 In the example below, the following notations will be used. 110 ==> means IPv6 packet. 111 --> means IPv4 packet. 112 ++> means IPv6 over IPv6 tunnel. 114 3.1 Control Sessions 116 3.1.1 Initial state 118 In initial state is in home network and it communicates 119 with like general NAT-PT outbound session. 121 122 | | | | 123 |======>|======>| | - sends IPv6 packet [src 124 | | | | (P1::xxxx/64),dst(PREFIX::a.b.c.d)] 125 | | | | to . 126 | | | | 127 | | |------->| - translates IPv6 packet 128 | | | | into IPv4 packet[src(w.x.y.z), 129 | | | | dst(a.b.c.d)] and sends it to 130 | | | | . 131 | | | | 132 | | |<-------| - sends IPv4 packet[src 133 | | | | (a.b.c.d),dst(w.x.y.z)] to 134 | | | | . 135 | | | | 136 |<======|<======| | - translates IPv4 packet 137 | | | | into IPv6 packet[src(PREFIX:: 138 | | | | a.b.c.d),dst(P1::xxxx/64)] 140 * IPv6 MN 141 P1::xxxx/64 (Home Address) 142 * HA 143 advertises P1::/64 144 * NAT-PT 145 advertises PREFIX::/64 146 Mapping Table: 147 mapping_entry[0] = {P1::xxxx/64, w.x.y.z} 148 Binding Cache Table: 149 binding_cache_entry[0] = {} 150 Kcn/nonce Table: 151 kcn_entry[0] = {} 152 * IPv4 CN 153 a.b.c.d 155 3.1.2 RR procedure 157 After 's moving from home network to other subnet, tries RR procedure to check reachability of before 159 sending BU. 161 162 | | | | | 163 |===========>|======>| | - sends CoTI message 164 | | | | | to . 165 | | | | | 166 |++++++>|===========>| | - sends HoTI message 167 | | | | | to through HA. 168 | | | | | 169 |<===========|<======| | - intercepts CoTI 170 | | | | | message and return CoT message 171 | | | | | to . Before sending 172 | | | | | CoT message, must 173 | | | | | save kcn and care-of nonce 174 | | | | | index for 175 | | | | | 176 |<++++++|<===========| | - intercepts HoTI 177 | | | | | message and return HoT message 178 | | | | | to . Before sending 179 | | | | | HoT message, must 180 | | | | | save kcn and home nonce index 181 | | | | | for 183 * IPv6 MN 184 P1::xxxx/64 (Home Address) 185 P2::xxxx/64 (Care of Address) 186 * HA 187 advertises P1::/64 188 * R1 189 advertises P2::/64 191 * NAT-PT 192 advertises PREFIX::/64 193 Mapping Table: 194 mapping_entry[0] = { P1::xxxx/64, w.x.y.z } 195 Binding Cache Table: 196 binding_cache_entry[0] = {} 197 Kcn/nonce Table: 198 kcn_entry[0] = { HA: P1::xxxx/64, COA: P2::xxxx/64, 199 CN: a.b.c.d, Kcn: nnn, 200 Home Nonce index: nnn, 201 Care-of Nonce Index: nnn } 202 * IPv4 CN 203 a.b.c.d 205 3.1.3 Binding Update/Acknowledge 207 After finishing RR procedure makes authenticator and 208 sends BU message to for route optimization. 210 211 | | | | | 212 |===========>|======>| | - sends BU message to 213 | | | | | 214 | | | | | 215 |<===========|<======| | - interceptes BU 216 | | | | | message and returns BA to 217 | | | | | . Before sending BA 218 | | | | | must add new binding 219 | | | | | cache entry. 221 * IPv6 MN 222 P1::xxxx/64 (Home Address) 223 P2::xxxx/64 (Care of Address) 224 * HA 225 advertises P1::/64 226 * R1 227 advertises P2::/64 228 * NAT-PT 229 advertises PREFIX::/64 230 Mapping Table: 231 mapping_entry[0] = { P1::xxxx/64, w.x.y.z } 232 Binding Cache Table: 233 binding_cache_entry[0] = { HA: P1::xxxx/64, 234 COA: P2::xxxx/64, 235 Lifetime: nnn, Flag: 0, 236 Seq no: nnn, Usage info: nnn} 237 Kcn/nonce Table: 238 kcn_entry[0] = { HA: P1::xxxx/64, COA: P2::xxxx/64, 239 CN: a.b.c.d, Kcn: nnn, 240 Home Nonce index: nnn, 241 Care-of Nonce Index: nnn } 243 * IPv4 CN 244 a.b.c.d 246 3.2 General Data Transimission 248 249 | | | | | 250 |===========>|======>| | - sends IPv6 packet 251 | | | | | with HAO to . 252 | | | | | 253 | | | |------->| - intercepts IPv6 254 | | | | | packet with HAO. To translate 255 | | | | | packet with HAO 256 | | | | | searches connection {src(HA), 257 | | | | | dst(PREFIX::a.b.c.d)} which 258 | | | | | has mapping information. 259 | | | | | 260 | | | |<-------| - sends IPv4 packet 261 | | | | | [src(a.b.c.d), dst(w.x.y.z)] 262 | | | | | to . 263 | | | | | 264 |<===========|<======| | - translates IPv4 265 | | | | | packet and forwards it. Before 266 | | | | | sending translated IPv6 packet 267 | | | | | must check whether 268 | | | | | there is binding cache entry 269 | | | | | corresponding to P1::xxxx/64 270 | | | | | or not. 271 | | | | | If there is binding cache 272 | | | | | entry, changes 273 | | | | | destination address into COA 274 | | | | | (P2::xxxx/64) and adds routing 275 | | | | | option header including HA 276 | | | | | (P1::xxxx/64) to basic IPv6 277 | | | | | header. 279 * IPv6 MN 280 P1::xxxx/64 (Home Address) 281 P2::xxxx/64 (Care of Address) 282 * HA 283 advertises P1::/64 284 * R1 285 advertises P2::/64 286 * NAT-PT 287 advertises PREFIX::/64 288 Mapping Table: 289 mapping_entry[0] = { P1::xxxx/64, w.x.y.z } 290 Binding Cache Table: 291 binding_cache_entry[0] = { HA: P1::xxxx/64, 292 COA: P2::xxxx/64, 293 Lifetime: nnn, Flag: 0, 294 Seq no: nnn, Usage info: nnn} 295 Kcn/nonce Table: 296 kcn_entry[0] = { HA: P1::xxxx/64, COA: P2::xxxx/64, 297 CN: a.b.c.d, Kcn: nnn, 298 Home Nonce index: nnn, 299 Care-of Nonce Index: nnn } 300 * IPv4 CN 301 a.b.c.d 303 4. IPv6-MNs move from one island to another island 305 This issue should be also considered. This version of the draft is 306 not mentioned yet. 308 5. Security Considerations 310 Security consideration is not studied yet. 312 8. Acknowledgments 314 Authors would like to acknowledge the idea sharing contributions by 315 Hee Cheol Lee and for detailed comments by KyeongJin Lee on this 316 document. 318 Normative References 320 [1] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Pro- 321 tocol Translation (NAT-PT)", RFC 2766, February 2000. 323 [2] J. Soininen (ed.), "Transition Scenarios for 3GPP Networks", draft- 324 ietf-v6ops-3gpp-cases-03, March 2003 (Work-in-Progress). 326 [3] J. Wiljakka (ed.), "Analysis on IPv6 Transition in 3GPP Networks", 327 draft-ietf-v6ops-3gpp-analysis-03, March 2003 (Work-in-Progress). 329 [4] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", 330 RFC-3775, June 2004. 332 [5] C. Perkins, Ed., "IP Mobility Support for IPv4", RFC 3344, August 333 2002 335 Authors' Addresses 337 Joo-Chul Lee 338 ETRI PEC 339 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea 340 Tel : +82 42 860 1080 341 Fax : +82 42 861 5404 342 E-mail : rune@etri.re.kr 344 Myung-Ki Shin 345 ETRI PEC 346 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea 347 Tel : +82 42 860 4847 348 Fax : +82 42 861 5404 349 E-mail : mkshin@pec.etri.re.kr 351 Intellectual Property Statement 353 The IETF takes no position regarding the validity or scope of any 354 Intellectual Property Rights or other rights that might be claimed to 355 pertain to the implementation or use of the technology described in 356 this document or the extent to which any license under such rights 357 might or might not be available; nor does it represent that it has 358 made any independent effort to identify any such rights. Information 359 on the procedures with respect to rights in RFC documents can be 360 found in BCP 78 and BCP 79. 362 Copies of IPR disclosures made to the IETF Secretariat and any 363 assurances of licenses to be made available, or the result of an 364 attempt made to obtain a general license or permission for the use of 365 such proprietary rights by implementers or users of this 366 specification can be obtained from the IETF on-line IPR repository at 367 http://www.ietf.org/ipr. 369 The IETF invites any interested party to bring to its attention any 370 copyrights, patents or patent applications, or other proprietary 371 rights that may cover technology that may be required to implement 372 this standard. Please address the information to the IETF at 373 ietf-ipr@ietf.org. 375 Disclaimer of Validity 377 This document and the information contained herein are provided on an 378 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 379 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 380 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 381 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 382 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 383 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 385 Copyright Statement 387 Copyright (C) The Internet Society (2005). This document is subject 388 to the rights, licenses and restrictions contained in BCP 78, and 389 except as set forth therein, the authors retain all their rights. 391 Acknowledgment 393 Funding for the RFC Editor function is currently provided by the 394 Internet Society.