idnits 2.17.00 (12 Aug 2021) /tmp/idnits62463/draft-oulai-netlmm-mip-interaction-v4support-00.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, updated by RFC 4748 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 303. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 7, 2008) is 5059 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) ** Downref: Normative reference to an Informational draft: draft-giaretta-netlmm-mip-interactions (ref. 'I-D.giaretta-netlmm-mip-interactions') == Outdated reference: draft-ietf-mext-nemo-v4traversal has been published as RFC 5555 == Outdated reference: draft-ietf-netlmm-pmip6-ipv4-support has been published as RFC 5844 == Outdated reference: draft-ietf-netlmm-proxymip6 has been published as RFC 5213 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netlmm Working Group D. Oulai 3 Internet-Draft S. Krishnan 4 Intended status: Standards Track Ericsson 5 Expires: January 8, 2009 July 7, 2008 7 IPv4 support in PMIP-MIP interaction 8 draft-oulai-netlmm-mip-interaction-v4support-00.txt 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 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 8, 2009. 35 Abstract 37 PMIPv6 and MIPv6 are respectively the leading protocols for network 38 based and client based mobility. As backward compatibility is an 39 important feature, IPv4 support for PMIPv6 and MIPv6 becomes 40 mandatory. This document highlights some scenarios for PMIPv6-MIPv6 41 interaction with IPv4 support as well as some proposed solutions. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Conventions used in this document . . . . . . . . . . . . . . 4 47 3. Scenario Analysis . . . . . . . . . . . . . . . . . . . . . . 5 48 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3.2. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 6 50 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 51 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 52 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 54 Intellectual Property and Copyright Statements . . . . . . . . . . 12 56 1. Introduction 58 MIPv6 is the IETF standard for client-based mobility [RFC3775] and 59 PMIPv6 is an extension of MIPv6 developped to offer network-based 60 mobility [I-D.ietf-netlmm-proxymip6]. For those two protocols, 61 backward compatibility is important and that is why IPv4 support 62 becomes mandatory. The IPv4 support for MIPv6 is provided by DSMIP 63 [I-D.ietf-mext-nemo-v4traversal] and PMIPv6-v4 handles the v4 support 64 for PMIPv6 [I-D.ietf-netlmm-pmip6-ipv4-support]. 66 Due to different reasons and network operator preferences, MIPv6 and 67 PMIPv6 will have to interact. A work is ongoing on PMIPv6-MIPv6 68 interaction [I-D.giaretta-netlmm-mip-interactions]. Three scenarios 69 have been presented. 71 * Scenario A: Two distincts PMIPv6 domains inside a single MIPv6 72 domain. 74 * Scenario B: A single domain where PMIPv6 and MIPv6 are offered. 76 * Scenario C: A colocated LMA/HA serving distincts PMIPv6 and MIPv6 77 domain. 79 In this document, we tackle the v4 support of this PMIPv6/MIPv6 80 interaction (PMIPv6-v4/DSMIP). First, note that we will not address 81 scenario B mentioned in [I-D.giaretta-netlmm-mip-interactions] as it 82 will not involve any handover. Direct applications of 83 [I-D.ietf-netlmm-pmip6-ipv4-support] and 84 [I-D.ietf-mext-nemo-v4traversal] can offer v4 support in scenario B. 85 For each remaining scenarios, we have to consider the case where both 86 source and target networks have v4 support and the case where target 87 network do not offer v4 support. Moreover, for scenario A, it is 88 possible that the global MIPv6 used for macro-mobility does not 89 support IPv4. 91 2. Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Scenario Analysis 99 In this section, we analyze and provide solutions for scenarios A and 100 C depicted in [I-D.giaretta-netlmm-mip-interactions] 102 3.1. Scenario A 104 In this scenario, we have two distincts PMIPv6 domains P1 and P2 105 inside a single global MIPv6 domain G. In case where both P1 and P2 106 do not support v4, the MN will use DSMIP with the HA to support v4 107 applications and mobility. For the remaining part of this section, 108 we assume that the MN is in the domain P1 that offers v4 support as 109 depicted in [I-D.ietf-netlmm-pmip6-ipv4-support]. Using PMIPv6-v4, 110 the MN acquires an IPv6 and an IPv4 HoA. Several situations could 111 occur. 113 * G domain supports v4 115 Beforehand, MN has to run the DSMIP bootstrapping mechanism while 116 residing in P1 to obtain DSMIP v6 and v4 HoA anchored at the HA. 117 Then, MN registers its PMIPv6 v6 or v4 HoA as CoA with HA while still 118 in P1. Preference is given to the v6 address in this case as there 119 can only be one CoA. All the v6 and v4 traffic flowing through HA 120 will be tunneled to MN using the CoA. The MN SHOULD use the v4 HoA 121 anchored at the HA at the transport level as the v4 CoA may change 122 after handover. However, the MN could use the v4 CoA for short-term 123 connections 125 v4 support in domain P2 : When moving to a P2 domain that offers v4 126 support, the MN acquires new v6 and v4 address. It registers its new 127 PMIPv6 v6 HoA as CoA with HA. All the v4 traffic from HA will be 128 encapsulated towards this CoA and the MN will encapsulate the v4 129 traffic with the HA address. The MN SHOULD use the v4 HoA anchored 130 at the HA at the transport level as the CoA may change after 131 handover. 133 No v4 support in domain P2 : In this case, the same process described 134 above is applyed except that the MN will not get a new PMIPv6 v4 HoA. 135 v4 support is handled by MN and HA running DSMIP. 137 * G domain does not supports v4 139 In this case, the v4 traffic is handled by the LMA1, the LMA in the 140 domain P1 using PMIPv6-v4 [I-D.ietf-netlmm-pmip6-ipv4-support]. We 141 recommand that LMA1 includes some DSMIP functionnalities. We will 142 have a colocated LMA1/HA1, similar to the one depicted in scenario C 143 of [I-D.giaretta-netlmm-mip-interactions] . The MN SHOULD be aware 144 that there is no v4 support at HA in domain G. 146 We also recommand to keep the v4 anchor identity in a policy profile. 147 If domain G supports v4, HA is the v4 anchor and if not, LMA1 is the 148 v4 anchor. After the handover in P2 and the PMIPv6 bootstrapping, 149 the MN interacts with the policy profile to get the v4 anchor (LMA1) 150 address and start a DSMIP bootstrapping process with LMA1. The MN 151 SHOULD include its previous v4 HoA in the IKEv2 exchange so this 152 address will be used as DSMIP v4 HoA at the LMA1. Therefore, the MN 153 will be able to continue using this address for v4 traffic. 155 For v6 trafic, implementation has two choices. First one is to keep 156 the tunneling between HA and LMA1 then tunnels the packet to the new 157 address in domain P2. The second option is to update the BCE at the 158 HA in the global domain to receive directly the v6 packets from the 159 HA. This is possible as v6 and v4 bindings are independent. 160 However, we recommend the first choice for simplicity. 162 3.2. Scenario C 164 We assume that the MN starts in a domain that offers v4 support. The 165 MN configures v6 and v4 HoA. 167 * Handover PMIPv6-MIPv6 169 MIPv6 domain supports v4 : In the DSMIP bootstrapping mechanism, the 170 addresses acquired in the PMIP domain are considered as v6 and v4 HoA 171 by the HA. For this purpose, a hint must be included in the IKEv2 172 exchange as mentioned in [I-D.giaretta-netlmm-mip-interactions]. MN 173 acquires new v4 and v6 addresses and registers the v6 address as CoA 174 with HA. Depending on the transport network in the MIPv6 domain, v4 175 or v6 encapsulation may be used. The principles of DSMIP will rule 176 the signaling and data transport. Also, the Binding Cache lookup 177 considerations as presented in [I-D.giaretta-netlmm-mip-interactions] 178 will also be applied. 180 MIPv6 domain does not support v4 : In this case, as the LMA and the 181 HA are colocated, the BCE at the HA will be modified to consider the 182 v4 HoA and the principles of DSMIP could be applied. 184 * Handover MIPv6-PMIPv6 186 PMIPv6 domain supports v4 : The addresses acquired in the MIPv6 187 domain are considered as v6 and v4 HoA by the LMA. The LMA will 188 propose the same Home Network Prefixes (HNP) as in the MIPv6 domain. 189 For this purpose, the HNP MUST be reserved as mentioned in 190 [I-D.ietf-netlmm-pmip6-ipv4-support]. PMIPv6-v4 will rule the 191 signaling and data transport. The Binding Cache lookup 192 considerations will be applied as presented in 193 [I-D.giaretta-netlmm-mip-interactions] . 195 PMIPv6 domain does not support v4 : In this case, the MN will used 196 the v6 HoA in the PMIP domain. The MN will send a binding update to 197 the HA. A modification is required to DSMIP allowing to have only a 198 v4 HoA. The BU message will tell the HA to keep only the v4 HoA in 199 the BCE and remove the v6 HoA. The MN will have two BCE. Therefore, 200 packets coming with the v6 HoA will be handled by the LMA and 201 forwarded to the MAG and packets coming with v4 address will be 202 handled by the HA, encapsulated and forwarded to the v6 HoA which is 203 the PMIPv6 v6 HoA. Another choice could be to configure a new v6 204 address in the PMIP domain and register it as CoA with the HA as in 205 scenario A. 207 4. Security Considerations 209 This document do not bring any new security issues compared to 210 [I-D.giaretta-netlmm-mip-interactions] . The BCE handling in 211 scenario C is the major task. 213 5. IANA Considerations 215 TBD 217 6. Normative References 219 [I-D.giaretta-netlmm-mip-interactions] 220 Giaretta, G., "Interactions between PMIPv6 and MIPv6: 221 scenarios and related issues", 222 draft-giaretta-netlmm-mip-interactions-02 (work in 223 progress), November 2007. 225 [I-D.ietf-mext-nemo-v4traversal] 226 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 227 Routers", draft-ietf-mext-nemo-v4traversal-04 (work in 228 progress), June 2008. 230 [I-D.ietf-netlmm-pmip6-ipv4-support] 231 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 232 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03 233 (work in progress), May 2008. 235 [I-D.ietf-netlmm-proxymip6] 236 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 237 and B. Patil, "Proxy Mobile IPv6", 238 draft-ietf-netlmm-proxymip6-18 (work in progress), 239 May 2008. 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, March 1997. 244 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 245 in IPv6", RFC 3775, June 2004. 247 Authors' Addresses 249 Desire Oulai 250 Ericsson 251 8400 Blvd Decarie 252 Town of Mount Royal, Quebec 253 Canada 255 Email: desire.oulai@ericsson.com 257 Suresh Krishnan 258 Ericsson 259 8400 Blvd Decarie 260 Town of Mount Royal, Quebec 261 Canada 263 Email: Suresh.Krishnan@ericsson.com 265 Full Copyright Statement 267 Copyright (C) The IETF Trust (2008). 269 This document is subject to the rights, licenses and restrictions 270 contained in BCP 78, and except as set forth therein, the authors 271 retain all their rights. 273 This document and the information contained herein are provided on an 274 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 275 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 276 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 277 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 278 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 279 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 281 Intellectual Property 283 The IETF takes no position regarding the validity or scope of any 284 Intellectual Property Rights or other rights that might be claimed to 285 pertain to the implementation or use of the technology described in 286 this document or the extent to which any license under such rights 287 might or might not be available; nor does it represent that it has 288 made any independent effort to identify any such rights. Information 289 on the procedures with respect to rights in RFC documents can be 290 found in BCP 78 and BCP 79. 292 Copies of IPR disclosures made to the IETF Secretariat and any 293 assurances of licenses to be made available, or the result of an 294 attempt made to obtain a general license or permission for the use of 295 such proprietary rights by implementers or users of this 296 specification can be obtained from the IETF on-line IPR repository at 297 http://www.ietf.org/ipr. 299 The IETF invites any interested party to bring to its attention any 300 copyrights, patents or patent applications, or other proprietary 301 rights that may cover technology that may be required to implement 302 this standard. Please address the information to the IETF at 303 ietf-ipr@ietf.org.