idnits 2.17.00 (12 Aug 2021) /tmp/idnits2853/draft-tschofenig-omipv6-multihoming-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 265. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 11, 2005) is 6157 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.haddad-mip6-cga-omipv6' == Outdated reference: A later version (-02) exists of draft-haddad-privacy-omipv6-anonymity-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.haddad-privacy-omipv6-anonymity' == Outdated reference: A later version (-03) exists of draft-haddad-momipriv-problem-statement-01 == Outdated reference: draft-ietf-mobike-design has been published as RFC 4621 == Outdated reference: draft-ietf-mobike-protocol has been published as RFC 4555 == Outdated reference: draft-ietf-send-cga has been published as RFC 3972 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Siemens 4 Expires: January 12, 2006 W. Haddad 5 Ericsson Research 6 July 11, 2005 8 OMIPv6 Multi-Homing and Privacy 9 draft-tschofenig-omipv6-multihoming-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on January 12, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The Optimized Mobile IPv6 with CGA (OMIPv6-CGA) protocol specifies a 43 new route optimization (RO) to solve the mobility problem. Privacy 44 extensions for OMIPv6 adds anonymity and unlinkability support to the 45 OMIPv6-CGA protocol. 47 This document combines OMIPv6-CGA including its privacy extension 48 with support for multi-homing. As such, it offers an efficient and 49 secure multi-homing and mobility support for MIPv6 using CGAs 50 including privacy support. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Strawman Protocol Proposal . . . . . . . . . . . . . . . . . . 3 57 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 9.1 Normative References . . . . . . . . . . . . . . . . . . . 5 64 9.2 Informative References . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 66 Intellectual Property and Copyright Statements . . . . . . . . 7 68 1. Introduction 70 Optimized Mobile IPv6 with CGA [I-D.haddad-mip6-cga-omipv6] protocol 71 specifies a new route optimization (RO) to solve the mobility 72 problem. Privacy extensions for OMIPv6 added anonymity and 73 unlinkability support to the OMIPv6-CGA protocol. 75 This document combines these previously mentioned documents and adds 76 multi-homing support. As such, it offers an efficient and secure 77 multi-homing and mobility support for MIPv6 using CGAs with privacy 78 support. 80 To provide multi-homing support based on [I-D.haddad-privacy-omipv6- 81 anonymity] requires to deal with the following aspects: 82 o Ability to inform the other peer about the peer address set 83 o Ability to inform the other peer about the preferred address 84 o Ability to test connectivity along a path and thereby to detect an 85 outage situation 86 o Ability to change the preferred address 87 o Ability to change the peer address set 89 Additionally, it is worth pointing out that a new care-of address 90 must be authorized prior to its usage. The procedure detailed in 91 OMIPv6 [I-D.haddad-mip6-cga-omipv6] and not repeated in this 92 document. Finally, the aspect of state indexing needs to be 93 considered. OMIPv6 selects the Binding Cache Entry (BCE) based on 94 the Home Address. The privacy extensions defined for OMIPv6 modify 95 this state selection approach and use a specially generated "Sequence 96 Value" (SQV). Since this document builds on top of the privacy 97 extensions for OMIPv6 SQV state indexing approach is reused. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 Terms, such as peer, peer address set, path or preferred address, are 106 reused from MOBIKE [I-D.ietf-mobike-design]. Terminology related to 107 OMIPv6 [I-D.haddad-mip6-cga-omipv6] and its privacy extension 108 [I-D.haddad-privacy-omipv6-anonymity] can be found in the respective 109 documents. 111 3. Strawman Protocol Proposal 113 This document requires the following protocol processing: 115 Ability to inform the other peer about the peer address set: 117 The MN indicates support for multihoming in the Binding Update 118 with a new payload ADDRESS_LIST that is an extended version of the 119 'Alternate Care-of address' payload. This new payload also 120 indicates the available addresses. 122 Ability to inform the other peer about the preferred address: 124 The source and the destination address of a packet directly sent 125 to the CN is the preferred address pair. 127 Ability to test connectivity: 129 Procedures for path testing need further study. This procedure 130 ensures that a currently used path stopped working. [Editor's 131 Note: Some words about congestion control for concurrent path 132 tests are needed.] 134 Ability to change the preferred address: 136 The source and the destination address of a packet directly sent 137 to the CN is the preferred address pair. As a policy the MN 138 thereby decides about the preferred address pair being used. This 139 allows the protocol to work if stateful packet filtering firewalls 140 are deployed in IPv6 networks. 142 Ability to change the peer address set: 144 The mobile node can change its peer address set at any time by 145 sending a new Binding Update with a modified list of addresses in 146 the ADDRESS_LIST payload. 148 [Editor's Note: Detailed protocol processing rules for the MN and the 149 CN will be described in a future version of the document.] 151 4. Packet Format 153 Editor's Note: A future version of this document will define the 154 following packet formats: 155 o Ability to carry the peer address set 156 o Ability to indicate the preferred address 157 o Ability to add / delete addresses from the peer address set. 159 5. Example 161 [Editor's Note: An example will be provided in a future draft 162 version.] 164 6. Security Considerations 166 The security properties of the extension defined in this document are 167 based on the OMIPv6-CGA [I-D.haddad-mip6-cga-omipv6] and subsequently 168 on the security of CGAs (see [I-D.ietf-send-cga]). Privacy related 169 aspects are discussed in [I-D.haddad-momipriv-problem-statement] and 170 in [I-D.haddad-privacy-omipv6-anonymity] and applicable to this 171 document. Mobility specific threats, such as traffic redirectly and 172 hijacking, third-party flooding and blackholing, are addressed by the 173 base OMIPv6-CGA proposal. 175 7. IANA Considerations 177 This document does not require actions by IANA. 179 8. Acknowledgments 181 The authors would like to thank Pasi Eronen for his work on the 182 MOBIKE protocol [I-D.ietf-mobike-protocol]. 184 9. References 186 9.1 Normative References 188 [I-D.haddad-mip6-cga-omipv6] 189 Haddad, W., "Applying Cryptographically Generated 190 Addresses to Optimize MIPv6 (CGA-OMIPv6)", 191 draft-haddad-mip6-cga-omipv6-04 (work in progress), 192 May 2005. 194 [I-D.haddad-privacy-omipv6-anonymity] 195 Haddad, W., "Anonymity and Unlinkability Extension for 196 CGA-OMIPv6", draft-haddad-privacy-omipv6-anonymity-00 197 (work in progress), June 2005. 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", March 1997. 202 9.2 Informative References 204 [I-D.haddad-momipriv-problem-statement] 205 Haddad, W., "Privacy for Mobile and Multi-homed Nodes: 206 MoMiPriv Problem Statement", 207 draft-haddad-momipriv-problem-statement-01 (work in 208 progress), February 2005. 210 [I-D.ietf-mobike-design] 211 Kivinen, T. and H. Tschofenig, "Design of the MOBIKE 212 protocol", draft-ietf-mobike-design-02 (work in progress), 213 February 2005. 215 [I-D.ietf-mobike-protocol] 216 Eronen, P., "IKEv2 Mobility and Multihoming Protocol 217 (MOBIKE)", draft-ietf-mobike-protocol-00 (work in 218 progress), June 2005. 220 [I-D.ietf-send-cga] 221 Aura, T., "Cryptographically Generated Addresses (CGA)", 222 draft-ietf-send-cga-06 (work in progress), April 2004. 224 Authors' Addresses 226 Hannes Tschofenig 227 Siemens 228 Otto-Hahn-Ring 6 229 Munich, Bavaria 81739 230 Germany 232 Email: Hannes.Tschofenig@siemens.com 234 Wassim Haddad 235 Ericsson Research 236 8400, Decarie Blvd 237 Town of Mount Royal, Quebec H4P 2N2 238 Canada 240 Phone: +1 514 345 7900 (#2334) 241 Email: Wassim.Haddad@ericsson.com 243 Intellectual Property Statement 245 The IETF takes no position regarding the validity or scope of any 246 Intellectual Property Rights or other rights that might be claimed to 247 pertain to the implementation or use of the technology described in 248 this document or the extent to which any license under such rights 249 might or might not be available; nor does it represent that it has 250 made any independent effort to identify any such rights. Information 251 on the procedures with respect to rights in RFC documents can be 252 found in BCP 78 and BCP 79. 254 Copies of IPR disclosures made to the IETF Secretariat and any 255 assurances of licenses to be made available, or the result of an 256 attempt made to obtain a general license or permission for the use of 257 such proprietary rights by implementers or users of this 258 specification can be obtained from the IETF on-line IPR repository at 259 http://www.ietf.org/ipr. 261 The IETF invites any interested party to bring to its attention any 262 copyrights, patents or patent applications, or other proprietary 263 rights that may cover technology that may be required to implement 264 this standard. Please address the information to the IETF at 265 ietf-ipr@ietf.org. 267 Disclaimer of Validity 269 This document and the information contained herein are provided on an 270 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 271 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 272 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 273 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 274 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 275 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 277 Copyright Statement 279 Copyright (C) The Internet Society (2005). This document is subject 280 to the rights, licenses and restrictions contained in BCP 78, and 281 except as set forth therein, the authors retain all their rights. 283 Acknowledgment 285 Funding for the RFC Editor function is currently provided by the 286 Internet Society.