idnits 2.17.1 draft-lee-v6ops-natpt-mobility-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 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 2003) is 7615 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 284, 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') == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-21 ** Obsolete normative reference: RFC 3344 (ref. '5') (Obsoleted by RFC 5944) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Joo-Chul Lee 3 Expires: December 2003 Myung-Ki Shin 4 ETRI 5 June 2003 7 Considerations for Mobility Support in NAT-PT 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsolete by other documents 21 at anytime. It is inappropriate to use Internet Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The document specifies considerations for mobility support in NAT- 33 PT (RFC-2766) [1]. 35 1. Introduction 37 NAT-PT (RFC-2766) enables end-nodes in IPv6 realm to communicate 38 with end-nodes in IPv4 realm and vice versa. RFC-2766 [1] needs 39 some fixes and/or applicability statements. Among them, there 40 exists considerations in NAT-PT [1] when IPv6 end-nodes move. 3GPP 41 drafts [2, 3] mention that there is a need for transltors, such as 42 NAT-PT, but in this case, current RFC-2766 [1] does not support 43 IPv6 mobile nodes. The document specifies considerations for 44 mobility support in NAT-PT (RFC-2766)[1]. 46 2. Issues with mobility support in NAT-PT 48 2.1 Movement of end-nodes in IPv6 realm (IPv6-MNs) 50 When IPv6 end-nodes move, there are issues should be considered in 51 RFC-2766. Basically, since mobile IPv6 (MIPv6) [4] provides route 52 optimization, NAT-PT box must update its associated address mapping 53 entries. As well, NAT-PT box needs appropriate handling of controls 54 such as RR (Return Routability), BU (Binding Update), etc. 56 +---------+ 57 +------------------------>| IPv4 CN | 58 | +---------+ 59 V IPv4 domain 60 +----------+ 61 /--------------| NAT-PT |-----------\ 62 / +----------+ \ 63 | / | | 64 | /-----/ | | 65 | / | | 66 | : +-------+ | 67 | : | R1 | | 68 | / +-------+ | 69 | +-------+ / \ | 70 | | HA | / +-------+ | 71 | +-------+ : | R2 | | 72 | | : +-------+ | 73 | | | | 74 | +-------+ | | 75 | |IPv6 MN|- - - + ------+---+- | 76 | +-------+ | | | 77 | . +-------+ | 78 | +- - - - -> |IPv6 MN| | 79 | Movement +-------+ | 80 \ / 81 \-------------------------------------/ 82 IPv6 realm 84 2.2 Movement of end-nodes in IPv4 realm (IPv4-MNs) 86 Obviously, there is no issue when IPv4 end-nodes move, since mobile 87 IPv4 (MIPv4) ][5] uses tunneling. 89 3. Mobility support in NAT-PT box 91 This section describes the case that an IPv6-MN moves from home 92 network to other network in the same IPv6 island. 94 Main consideration is that NAT-PT box does all of MIPv6 95 functionalities on behalf of IPv4-CNs. Following subsections show 96 how NAT-PT box works in this situation. 98 In the example below, the following notations will be used. 100 ==> means IPv6 packet. 101 --> means IPv4 packet. 102 ++> means IPv6 over IPv6 tunnel. 104 3.1 Control Sessions 106 3.1.1 Initial state 108 In initial state is in home network and it communicates 109 with like general NAT-PT outbound session. 111 112 | | | | 113 |======>|======>| | - sends IPv6 packet [src 114 | | | | (P1::xxxx/64),dst(PREFIX::a.b.c.d)] 115 | | | | to . 116 | | | | 117 | | |------->| - translates IPv6 packet 118 | | | | into IPv4 packet[src(w.x.y.z), 119 | | | | dst(a.b.c.d)] and sends it to 120 | | | | . 121 | | | | 122 | | |<-------| - sends IPv4 packet[src 123 | | | | (a.b.c.d),dst(w.x.y.z)] to 124 | | | | . 125 | | | | 126 |<======|<======| | - translates IPv4 packet 127 | | | | into IPv6 packet[src(PREFIX:: 128 | | | | a.b.c.d),dst(P1::xxxx/64)] 130 * IPv6 MN 131 P1::xxxx/64 (Home Address) 132 * HA 133 advertises P1::/64 134 * NAT-PT 135 advertises PREFIX::/64 136 Mapping Table: 137 mapping_entry[0] = {P1::xxxx/64, w.x.y.z} 138 Binding Cache Table: 139 binding_cache_entry[0] = {} 140 Kcn/nonce Table: 141 kcn_entry[0] = {} 142 * IPv4 CN 143 a.b.c.d 145 3.1.2 RR procedure 147 After 's moving from home network to other subnet, tries RR procedure to check reachability of before 149 sending BU. 151 152 | | | | | 153 |===========>|======>| | - sends CoTI message 154 | | | | | to . 155 | | | | | 156 |++++++>|===========>| | - sends HoTI message 157 | | | | | to through HA. 158 | | | | | 159 |<===========|<======| | - intercepts CoTI 160 | | | | | message and return CoT message 161 | | | | | to . Before sending 162 | | | | | CoT message, must 163 | | | | | save kcn and care-of nonce 164 | | | | | index for 165 | | | | | 166 |<++++++|<===========| | - intercepts HoTI 167 | | | | | message and return HoT message 168 | | | | | to . Before sending 169 | | | | | HoT message, must 170 | | | | | save kcn and home nonce index 171 | | | | | for 173 * IPv6 MN 174 P1::xxxx/64 (Home Address) 175 P2::xxxx/64 (Care of Address) 176 * HA 177 advertises P1::/64 178 * R1 179 advertises P2::/64 180 * NAT-PT 181 advertises PREFIX::/64 182 Mapping Table: 183 mapping_entry[0] = { P1::xxxx/64, w.x.y.z } 184 Binding Cache Table: 185 binding_cache_entry[0] = {} 186 Kcn/nonce Table: 187 kcn_entry[0] = { HA: P1::xxxx/64, COA: P2::xxxx/64, 188 CN: a.b.c.d, Kcn: nnn, 189 Home Nonce index: nnn, 190 Care-of Nonce Index: nnn } 191 * IPv4 CN 192 a.b.c.d 194 3.1.3 Binding Update/Acknowledge 195 After finishing RR procedure makes authenticator and 196 sends BU message to for route optimization. 198 199 | | | | | 200 |===========>|======>| | - sends BU message to 201 | | | | | 202 | | | | | 203 |<===========|<======| | - interceptes BU 204 | | | | | message and returns BA to 205 | | | | | . Before sending BA 206 | | | | | must add new binding 207 | | | | | cache entry. 209 * IPv6 MN 210 P1::xxxx/64 (Home Address) 211 P2::xxxx/64 (Care of Address) 212 * HA 213 advertises P1::/64 214 * R1 215 advertises P2::/64 216 * NAT-PT 217 advertises PREFIX::/64 218 Mapping Table: 219 mapping_entry[0] = { P1::xxxx/64, w.x.y.z } 220 Binding Cache Table: 221 binding_cache_entry[0] = { HA: P1::xxxx/64, 222 COA: P2::xxxx/64, 223 Lifetime: nnn, Flag: 0, 224 Seq no: nnn, Usage info: nnn} 225 Kcn/nonce Table: 226 kcn_entry[0] = { HA: P1::xxxx/64, COA: P2::xxxx/64, 227 CN: a.b.c.d, Kcn: nnn, 228 Home Nonce index: nnn, 229 Care-of Nonce Index: nnn } 230 * IPv4 CN 231 a.b.c.d 233 3.2 General Data Transimission 235 236 | | | | | 237 |===========>|======>| | - sends IPv6 packet 238 | | | | | with HAO to . 239 | | | | | 240 | | | |------->| - intercepts IPv6 241 | | | | | packet with HAO. To translate 242 | | | | | packet with HAO 243 | | | | | searches connection {src(HA), 244 | | | | | dst(PREFIX::a.b.c.d)} which 245 | | | | | has mapping information. 247 | | | | | 248 | | | |<-------| - sends IPv4 packet 249 | | | | | [src(a.b.c.d), dst(w.x.y.z)] 250 | | | | | to . 251 | | | | | 252 |<===========|<======| | - translates IPv4 253 | | | | | packet and forwards it. Before 254 | | | | | sending translated IPv6 packet 255 | | | | | must check whether 256 | | | | | there is binding cache entry 257 | | | | | corresponding to P1::xxxx/64 258 | | | | | or not. 259 | | | | | If there is binding cache 260 | | | | | entry, changes 261 | | | | | destination address into COA 262 | | | | | (P2::xxxx/64) and adds routing 263 | | | | | option header including HA 264 | | | | | (P1::xxxx/64) to basic IPv6 265 | | | | | header. 267 * IPv6 MN 268 P1::xxxx/64 (Home Address) 269 P2::xxxx/64 (Care of Address) 270 * HA 271 advertises P1::/64 272 * R1 273 advertises P2::/64 274 * NAT-PT 275 advertises PREFIX::/64 276 Mapping Table: 277 mapping_entry[0] = { P1::xxxx/64, w.x.y.z } 278 Binding Cache Table: 279 binding_cache_entry[0] = { HA: P1::xxxx/64, 280 COA: P2::xxxx/64, 281 Lifetime: nnn, Flag: 0, 282 Seq no: nnn, Usage info: nnn} 283 Kcn/nonce Table: 284 kcn_entry[0] = { HA: P1::xxxx/64, COA: P2::xxxx/64, 285 CN: a.b.c.d, Kcn: nnn, 286 Home Nonce index: nnn, 287 Care-of Nonce Index: nnn } 288 * IPv4 CN 289 a.b.c.d 291 4. IPv6-MNs move from one island to another island 293 This issue should be also considered. This version of the draft is 294 not mentioned yet. 296 5. Security Considerations 297 Security consideration is not studied yet. 299 8. Acknowledgments 301 Authors would like to acknowledge the idea sharing contributions by 302 Hee Cheol Lee and for detailed comments by KyeongJin Lee on this 303 document. 305 References 307 [1] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 308 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 310 [2] J. Soininen (ed.), "Transition Scenarios for 3GPP Networks", 311 draft-ietf-v6ops-3gpp-cases-03, March 2003 (Work-in-Progress). 313 [3] J. Wiljakka (ed.), "Analysis on IPv6 Transition in 3GPP Networks", 314 draft-ietf-v6ops-3gpp-analysis-03, March 2003 (Work-in-Progress). 316 [4] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", 317 draft-ietf-mobileip-ipv6-21, February 2003 (Work-in-Progress). 319 [5] C. Perkins, Ed., "IP Mobility Support for IPv4", RFC 3344, August 320 2002 322 Authors' Addresses 324 Joo-Chul Lee 325 ETRI PEC 326 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea 327 Tel : +82 42 860 1080 328 Fax : +82 42 861 5404 329 E-mail : rune@etri.re.kr 331 Myung-Ki Shin 332 ETRI PEC 333 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea 334 Tel : +82 42 860 4847 335 Fax : +82 42 861 5404 336 E-mail : mkshin@pec.etri.re.kr