idnits 2.17.1 draft-boc-netext-lr-roext-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 22, 2013) is 4020 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boc 3 Internet-Draft C. Janneteau 4 Intended status: Informational A. Petrescu 5 Expires: October 24, 2013 CEA 6 April 22, 2013 8 RO Extensions for PMIPv6-LR (ROEXT) 9 draft-boc-netext-lr-roext-05.txt 11 Abstract 13 The communication path between two Hosts within a Proxy Mobile IPv6 14 domain is artificially long - it involves the LMA, even if straight 15 paths exist (under same MAG, or MAG-to-MAG). Localized Routing 16 PMIPv6-LR concepts developped by NETEXT WG make use of LRI/LRA 17 messages to achieve optimized MAG-to-MAG straight paths. This may 18 prove inconvenient for the network operator, in that it may loose 19 ability to control traffic (LMA control point is skipped). 21 In this draft we present a middle-ground solution. It employs new 22 Intermediary Anchors (IAs) in the paths between MAGs and offers 23 points of control of traffic useful for QoS and lawful interception. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 24, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 72 2. Concentrated Description . . . . . . . . . . . . . . . . . . . 5 73 3. LMA Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4. MAG Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 10 75 5. IA Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 78 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 79 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Requirements notation 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Concentrated Description 90 The work presented in this draft is developped in the context of 91 Proxy Mobile IPv6 [RFC5213] and uses LRI/LRA messages used by 92 Localized Routing [I-D.ietf-netext-pmip-lr]. 94 The relevant scenarios are represented by communication between two 95 Hosts typically situated each under a different MAG. 97 ----- ----- 98 | LMA | | LMA | 99 ----- ----- 100 / \ / \ 101 / / \ \ / \ 102 / / \ \ / \signalling 103 / /T1 \ \T2 / \ 104 / \ / \ 105 ----- ----- / \ 106 | MAG1| | MAG2| / \ 107 ----- ----- ----- ================== ----- 108 | | | MAG1| Direct Tunnel | MAG2| 109 | | ----- ----- 110 --|-- --|-- | | 111 |Host1| |Host2| --|-- --|-- 112 ----- ----- |Host1| |Host2| 113 ----- ----- 115 In this figure, on the left side, the established tunnels T1 and T2 116 for communication between Host1 and Host2 are shown, after the Proxy 117 Mobile IPv6 protocol has executed. Each tunnel is established 118 between LMA and the MAG under which a Host is attached. This 119 illustration is typically used to express a problem of too long 120 communication paths. 122 In the right part of the same figure, the Direct Tunnel between two 123 MAGs is illustrated as a solution to the problem of artificially long 124 paths through LMA. This is achieved by using Localized Routing 125 concepts of Proxy Mobile IPv6. The diagonal lines represent 126 signalling (not wires). 128 There may exist situations when MAG-LMA-MAG communication paths are 129 too long and yet the straight MAG-MAG paths may prove disadvantageous 130 in terms of loss of operator control on various aspects of the 131 traffic. A middle ground solution as a bent arch path (not fully 132 triangular, not fully straight) may be needed. 134 ----- 135 | LMA | 136 ----- 137 / | \ 138 / | \ 139 / | \signalling 140 / | \ 141 / | \ 142 / | \ 143 / ---- \ 144 ----- =====| IA |======= ----- 145 | MAG1| T1 ---- T2 | MAG2| 146 ----- ----- 147 | | 148 --|-- --|-- 149 |Host1| |Host2| 150 ----- ----- 152 In this figure a new entity is added between MAGs - the Intermediate 153 Anchor (IA). The tunnels T1 and T2 are established between the IA 154 and the two MAGs respectively (instead of LMA). The IA serves 155 purposes such as ensuring a certain level of control over the route 156 optimized traffic, such as providing a certain level of Quality-of- 157 Service, or, potentially, enabling data traffic enforcement for 158 lawful interception. Several such IAs may be placed at strategic 159 points within the Proxy Mobile IPv6 domain. 161 The LMA is pre-configured statically with information about the IP 162 addresses of all MAGs, and, new, IAs in the Proxy Mobile IPv6 domain. 164 To illustrate this procedure in a generic manner, we consider two IAs 165 instead of one. In the following figure, we assume that IA1 and IA2 166 are positioned in a "sequential" manner between the MAG1 and MAG2. 167 This is to illustrate that the mechanism pertains to situations where 168 more IAs are used, and not only one. 170 Initially, H1 and H2 exchange Data through the tunnels setup by Proxy 171 Mobile IPv6, via LMA and the respective MAGs (the first 4 double- 172 arrowed lines at the top of the illustration) . 174 H1 H2 MAG1 MAG2 IA1 IA2 LMA 175 | | Data | | | | | 176 |<---------------->| | | | Data | 177 | | |<--------------------------------->| 178 | | | | | | Data | via LMA 179 | | | Data |<----------------------->| and MAG 180 | |<----------------->| | | | 181 | | | | | | | 182 | | |[Trigger RO procedure] |LRI_IA1 | 183 | | | | |<---------------| 184 | | | | |LRA_IA1| | 185 | | | | |--------------->| 186 | | | | | |LRI_IA2 | RO 187 | | | | | |<-------| configure 188 | | | | | |LRA_IA2 | 189 | | | | | |------->| 190 | | | LRI_MAG1 | | | 191 | | |<--------------------------------- | 192 | | | LRA_MAG1 | | | 193 | | |---------------------------------->| 194 | | | | LRI_MAG2 | | 195 | | | |<------------------------| 196 | | | | LRA_MAG2 | | 197 | | | |------------------------>| 198 | Data | | | | | 199 |<---------------->| Data | | | | 200 | | |<---------------->| | | 201 | | | | | Data | | 202 | | | | |<----->| | 203 | | | | Data | | | via IA 204 | | | |<-------------->| | and MAG 205 | | Data | | | | | 206 | |<----------------->| | | | 208 Subsequently, a certain trigger (to be defined) starts the Route 209 Optimization procedure. The procedure consists in LRI and LRA 210 messages. The LMA sends an LRI to IA1 and to IA2 respectively. In a 211 same centralized manner, LMA sends the same type of messages to MAG1 212 and MAG2 respectively. There are as many LRI messages as there are 213 IAs plus (always) two MAGs. The LRI messages instruct the receivers 214 about the IP addresses of the entities in question. For example, 215 LRI_IA1 informs IA1 about the IP address of IA2. 217 When the last LRA has been received from a second MAG, it can be 218 considered that the paths have been "route optimized", i.e. LMA is 219 no longer in the path. The Data traffic between H1 and H2 is 220 exchanged via IAs and MAGs exclusively (LMA is skipped). 222 The following diagram shows a modified LRI message. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Sequence # | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |R|S|I| Reserved | Lifetime | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 . . 233 . Mobility options . 234 . . 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 'I' flag: if set to 1 it indicates that this message is for an 239 Intermediate Anchor. 241 The following diagram shows a modified LRA message. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Sequence # | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |R|U|I| Reserved| Status | Lifetime | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 . . 252 . Mobility options . 253 . . 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 'I' flag: if set to 1 it indicates that this message is is sent by an 258 Intermediate Anchor. 260 3. LMA Behaviour 262 LMA is pre-configured with each address of each MAG and of each IA in 263 the Proxy Mobile IPv6 domain. In addition, it has topology 264 information about the placement of these entities (IA, MAG) with 265 respect to each other, and can know the IP distances (hopcount) 266 between each to each other. For example, for two given MAGs, it 267 knows the shortest path and the IP addresses of the intervening IAs. 269 LMA is expecting a trigger indicating that the Route Optimization 270 procedure should start. This trigger is to be defined. In one 271 sense, LMA could deduce this trigger when its Binding Cache is 272 updated. Speculatively, the addresses stored in the Binding Cache 273 could indicate that two Hosts are under MAGs of same LMA, and that 274 their tunnels are using LMA. 276 The LMA emits LRI messages and, for each LRI sent it waits for an 277 LRA. It sends the following LRI only when the preceding LRI has been 278 arcknowledged by an LRA. 280 4. MAG Behaviour 282 MAG receives LRI messages, and does not generate such. When LRI is 283 received, it executes indications contained in it. Upon completion, 284 it sends LRA to the originator of the LRI (the LMA) explaining the 285 success or error of execution. MAG does not receive LRA. 287 5. IA Behaviour 289 IA behaviour is similar to that of MAG. 291 6. Security Considerations 293 Lawful interception is probably the single most unique kind of 294 requirement difficult to fit within the otherwise very powerful 295 security architecture of Internet. It is not immediately obvious 296 whether techniques addressing this particular requirement effectively 297 influence or are influenced by Internet security. 299 LRI and LRA messages should be protected by using IPsec. 301 7. Acknowledgements 303 Other than Authors, a number of persons are involved with 304 implementation and protection of this technique. For example, 305 Sofiane Imadali is designing and implementing a testbed prototype 306 with C, linux and Ethernet, under wise guidance of advisor. 308 Administratively, this work has been performed in the framework of 309 CELTIC project CP7-011 MEVICO. The authors would like to acknowledge 310 the contributions of their colleagues, although the views expressed 311 are those of the authors and do not necessarily represent the 312 project. 314 8. Normative References 316 [I-D.ietf-netext-pmip-lr] 317 Krishnan, S., Koodli, R., Loureiro, P., Wu, W., and A. 318 Dutta, "Localized Routing for Proxy Mobile IPv6", 319 draft-ietf-netext-pmip-lr-10 (work in progress), May 2012. 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 325 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 327 Appendix A. ChangeLog 329 The changes are listed in reverse chronological order, most recent 330 changes appearing at the top of the list. 332 From draft-boc-netext-lr-roext-04.txt to 333 draft-boc-netext-lr-roext-05.txt: 335 o Date change, no content change. 337 From draft-boc-netext-lr-roext-03.txt to 338 draft-boc-netext-lr-roext-04.txt: 340 o Date change, no content change. 342 From draft-boc-netext-lr-roext-01.txt to 343 draft-boc-netext-lr-roext-02.txt: 345 o Changed affiliation from "CEA LIST" to "CEA, LIST" to respect 346 local guidelines. 348 From draft-boc-netext-lr-roext-00.txt to 349 draft-boc-netext-lr-roext-01.txt: 351 o The -00 version was mostly a placeholder. Now with -01 we updated 352 the message exchange diagram and added its respective explanatory 353 text. 355 o Added new sections intended to describe behaviour per entity (LMA, 356 IA, MAG). 358 Authors' Addresses 360 Michael Mathias Boc 361 CEA, LIST 362 Communicating Systems Laboratory, Point Courrier 173 363 Gif-sur-Yvette, F-91191 364 France 366 Phone: +33 169083976 367 Email: michael.boc@cea.fr 369 Christophe Janneteau 370 CEA, LIST 371 Communicating Systems Laboratory, Point Courrier 173 372 Gif-sur-Yvette, F-91191 373 France 375 Phone: +33 (0) 169089182 376 Email: christophe.janneteau@cea.fr 378 Alexandru Petrescu 379 CEA, LIST 380 Communicating Systems Laboratory, Point Courrier 173 381 Gif-sur-Yvette, F-91191 382 France 384 Phone: +33 (0) 169089223 385 Email: alexandru.petrescu@cea.fr