idnits 2.17.1 draft-bernardos-mif-pmip-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors Copyright Line does not match the current year -- The document date (March 8, 2010) is 5157 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-mif-current-practices-00 == Outdated reference: A later version (-15) exists of draft-ietf-mif-problem-statement-01 == Outdated reference: A later version (-02) exists of draft-jeyatharan-netext-multihoming-ps-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT Working Group CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Experimental T. Melia 5 Expires: September 9, 2010 Alcatel-Lucent Bell Labs 6 P. Seite 7 France Telecom 8 J. Korhonen 9 Nokia Siemens Networks 10 March 8, 2010 12 Multihoming extensions for Proxy Mobile IPv6 13 draft-bernardos-mif-pmip-02 15 Abstract 17 The IETF standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables 18 mobile devices to connect to a PMIPv6 domain and roam across gateways 19 without changing the IP address. PMIPv6 also provides limited multi- 20 homing support to multi-mode mobile devices. The IETF is working on 21 optimizations for PMIPv6. While multi-homing item has been proposed 22 to be part of the approved work, discussions showed there are still 23 many controversial issues to be addressed (i.e. the no-host 24 modification theorem). This document explores solutions for the 25 multi-homing use case aiming at helping PMIPv6 development where 26 possible. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on September 9, 2010. 56 Copyright Notice 58 Copyright (c) 2010 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. MIF scope and PMIPv6 . . . . . . . . . . . . . . . . . . . . . 5 75 3. A use case . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. Considerations on feasibility and approach overview . . . . . 7 77 4.1. MN considerations . . . . . . . . . . . . . . . . . . . . 8 78 4.2. LMA considerations . . . . . . . . . . . . . . . . . . . . 9 79 4.3. MAG considerations . . . . . . . . . . . . . . . . . . . . 9 80 4.4. Downlink and Uplink considerations . . . . . . . . . . . . 10 81 4.5. IPv4 considerations . . . . . . . . . . . . . . . . . . . 10 82 5. Implementation Experience . . . . . . . . . . . . . . . . . . 11 83 5.1. Test setup . . . . . . . . . . . . . . . . . . . . . . . . 11 84 5.2. Attachment phase . . . . . . . . . . . . . . . . . . . . . 12 85 5.2.1. MAG considerations . . . . . . . . . . . . . . . . . . 12 86 5.2.2. LMA considerations . . . . . . . . . . . . . . . . . . 13 87 5.2.3. Miscellaneous considerations . . . . . . . . . . . . . 13 88 5.3. Flow Management . . . . . . . . . . . . . . . . . . . . . 13 89 5.3.1. Flow identification . . . . . . . . . . . . . . . . . 14 90 5.3.2. Flow routing . . . . . . . . . . . . . . . . . . . . . 15 91 5.4. Extensions on the MN . . . . . . . . . . . . . . . . . . . 16 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 Proxy Mobile IPv6 (PMIPv6), specified in RFC 5213 [RFC5213] and 103 [I-D.ietf-netlmm-pmip6-ipv4-support], provides network based mobility 104 management to hosts connecting to a PMIPv6 domain. PMIPv6 introduces 105 two new functional entities, the Local Mobility Anchor (LMA) and the 106 Mobility Access Gateway (MAG). The MAG is the first layer three hop 107 detecting Mobile Node (MN) attachment and providing IP connectivity. 108 The LMA is the entity assigning one or more Home Network Prefixes 109 (HNPs) and zero or one IPv4 Home Address (IPv4-MN-HoA)to the MN and 110 is the topological anchor for all traffic from/to the MN. 112 PMIPv6 allows an MN to connect to the same PMIPv6 domain through 113 different interfaces. ID 114 [I-D.devarapalli-netext-multi-interface-support] identifies at least 115 three possible scenarios, namely i) unique prefix per interface, ii) 116 same prefix but different global addresses per interface, iii) shared 117 address across multiple interfaces. The ID further describes issues 118 associated with each scenario. The first two scenarios are similar, 119 and bring similar issues, whereas the third one is more complex to 120 tackle, since it requires to deal with the sharing of the same IP 121 address across different interfaces. This document focuses on the 122 two first scenarios, as depicted in Figure 1. However, if [RFC1918] 123 defined private IPv4 addresses are used as IPv4 Home Addresses, the 124 scenario iii) may happen implicitly. Unless the LMA coordinates 125 private IPv4 Home Addresses across different access technologies and 126 mobility session, then there is a possibility that the same private 127 IPv4 Home Address would be assigned to both if1 and if2 of the MN. 129 LMA Binding Cache 130 +----+ ----------------- 131 |LMA | MN:if1 [prefix1 or addr1] --> MAG1 132 +----+ MN:if2 [prefix2 or addr1] --> MAG2 133 //\\ 134 +---------//--\\-------------+ 135 ( // \\ ) PMIPv6 domain 136 ( // \\ ) 137 +------//--------\\----------+ 138 // \\ 139 // \\ 140 +----+ +----+ 141 |MAG1| |MAG2| 142 +----+ +----+ 143 | | 144 | | 145 | if1 if2 | 146 +------[MN]------+ 148 Figure 1: Unique prefix and Unique address per Interface scenarios 150 The fact is that many (client) hosts currently have the ability to 151 attach to multiple networks simultaneously, and that implies benefits 152 (e.g., enables load balancing, improved connectivity, higher 153 throughput and better reliability, etc.), but also brings some 154 operation issues (e.g., default router selection, address selection, 155 DNS server selection, choice of interface for packet transmission, 156 the treatment of configuration information received from the various 157 networks, etc.). Configuration decisions about how to deal with the 158 different information from each of the interface might have a very 159 strong impact on the connectivity experienced by a node with multiple 160 network interfaces (from now on we refer a node with multiple network 161 interfaces as a MIF node). 163 In the context of PMIPv6, current specification [RFC5213] does not 164 address the case of a MIF node attaching to a PMIPv6 domain other 165 than stating it is possible. We argue it is important to enable 166 PMIPv6 to bring MIF nodes the advantages related to the simultaneous 167 use of multiple interfaces. Moreover a MIF node could be seen as a 168 not-modified host implementing the right technology for multi- 169 interface handling. 171 2. MIF scope and PMIPv6 173 Current scope of MIF nodes as described in 174 [I-D.ietf-mif-problem-statement] only covers the issues of host 175 attaching to multiple networks. The current work is focused on 176 documenting the system level effects to host IP stacks and 177 identification of gaps between the existing IETF recommendations and 178 existing practice, both for IPv4 and IPv6. 180 While [I-D.ietf-mif-problem-statement] is not addressing any (neither 181 flow nor host nor network) mobility, a MIF node might find itself 182 connected to a PMIPv6 domain. PMIPv6 should be extended to 183 efficiently support MIF nodes attaching to a PMIPv6 domain, enabling 184 features such as the ones identified in 185 [I-D.jeyatharan-netext-multihoming-ps], e.g., dynamic mobility 186 sessions between different interfaces, allowing traffic to be 187 forwarded to any of the interfaces of a MIF node, not only to the one 188 configured with the destination prefix/address of that traffic). 190 3. A use case 192 This section describes a simple use case of a MIF node in a PMIPv6 193 domain, as an example of a situation where PMIPv6 needs to be 194 extended. 196 +-----+ 197 | CN1 | 198 +-----+ 199 | LMA Binding Cache 200 | ===================== 201 | MN:if1, pref1, MAG1 202 +-----+ +-----+ :if2, pref2, MAG2 203 | CN2 |--------| LMA | 204 +-----+ +-----+ 205 //\\ 206 +---------//--\\-------------+ 207 ( // \\ ) PMIPv6 domain 208 ( // \\ ) 209 +------//--------\\----------+ 210 // \\ 211 // \\ 212 +----+ +----+ 213 |MAG1| |MAG2| 214 +----+ +----+ 215 | | 216 | | 217 | if1 if2 | 218 +-------[MN]------+ 219 (WLAN) (3G) 221 Figure 2: Use case 223 Figure 2 shows a potential use case of interest involving an MIF 224 mobile node attached to a PMIPv6 domain. The MN is attached to MAG1 225 through its WLAN interface (if1), and to MAG2 through its 3G 226 interface (if2). Lets consider the case in which each interface has 227 been assigned a different prefix by the LMA (for the sake of 228 simplicity we have left the IPv4 case out of this example). Two 229 different mobility bindings are created in the LMA referring to the 230 MN. In this scenario, if the MN decides to move if1 from MAG1 to a 231 different MAG of the same domain, the PMIPv6 support would take care 232 of ensuring that the same prefix (pref1) is assigned at the new MAG 233 (we assume that there is an L2 identifier for if1 that the new MAG 234 can include in the PBU). 236 Lets assume for the sake of this example that the MN starts a 237 communication with CN1, using as source IPv6 address (pref1::if1) the 238 one assigned to its WLAN interface (if1), and that it also starts a 239 different communication with CN2, using as source IPv6 address 240 (pref2::if2) the one assigned to its 3G interface (if2). In this 241 scenario, it would be useful to enable the MN be able to receive 242 traffic addressed to pref1::if1 via if2 and vice versa. However, 243 current PMIPv6 specification does not support this. Analogously, it 244 would be also useful to allow the MN send traffic with source address 245 pref1::if1 through if2 and vice versa. 247 We argue in the next section that PMIPv6 could benefit from MIF 248 outcomes to support the previous scenario while limiting impact on 249 the LMA and MAG operation. 251 4. Considerations on feasibility and approach overview 253 We analyse in the next sections the feasibility of the scenario 254 presented in Section 3, by identifying the requirements and changes 255 that would be needed in PMIPv6 to support it. In this version of the 256 document we do not specify with all the required details the 257 solution, but rather concentrate on the concept, with the goal of 258 triggering the discussion within the IETF. 260 Figure 3 shows in a glimpse the extensions to PMIPv6 required to 261 support the MIF example scenario shown in Section 3. 263 +-----+ 264 | CN1 | 265 +-----+ 266 | LMA Binding Cache LMA policy/routing table 267 | ===================== ============================ 268 | MN:if1, pref1, MAG1 flow1(CN1,MN[pref1])->MAG2 269 +-----+ +-----+ :if2, pref2, MAG2 flow2(CN1,MN[pref2])->MAG2 270 | CN2 |-----| LMA | ... 271 +-----+ +-----+ flowN(CN2,MN[pref1])->MAG1 272 //\\ 273 +---------//--\\-------------+ 274 ( // \\ ) PMIPv6 domain 275 ( // \\ ) 276 +------//--------\\----------+ 277 // \\ 278 // \\ MAG2 routing table 279 +----+ +----+ ================================ 280 |MAG1| |MAG2| (dest) (next hop) 281 +----+ +----+ pref2::/64 directly connected 282 | | pref1::/64 directly connected 283 | | 284 | if1 if2 | 285 +-------[MN]------+ MN implements the weak host model 286 (WLAN) (3G) 288 Figure 3: Solution overview 290 4.1. MN considerations 292 In order to support the reception of traffic addressed to pref1::if1 293 at the interface if2, the MN MUST follow the Weak host model 294 [RFC1122], [I-D.thaler-ip-model-evolution]. This model does not 295 limit traffic reception at a host only to IP packets whose 296 destination address matches the IP address assigned to the interface 297 receiving the packets, but allows to receive and process packets 298 whose IP destination address corresponds to that of any of the local 299 interfaces of the host. 301 By implementing the Weak host model, the MN in Figure 3 would be able 302 to process traffic addressed to any of its IP addresses (i.e., 303 pref1::if1 and pref2::if2), no matter to which interface that traffic 304 arrives to. 306 We have performed some tests with different operating systems, and 307 the results show that both Linux (tested with Linux-2.6.26) and Mac 308 OS X (tested with Leopard) implements the Weak host model for both 309 IPv4 and IPv6 traffic. We have not performed tests with Windows, but 310 some results have been reported in [I-D.ietf-mif-current-practices]. 312 It should be noted that Windows XP and Windows Server 2003 use the 313 Weak host model for sends and receives for all IPv4 interfaces and 314 the Strong host model for sends and receives for all IPv6 interfaces. 315 This behavior cannot be modified. The Next Generation TCP/IP stack 316 in Windows Vista and Windows Server 2008 supports strong host sends 317 and receives for both IPv4 and IPv6 by default on all interfaces. 318 The stack can be configured to use weak host model. 320 Generally it should be possible to enable automatic configuration of 321 the weak model during network attachment/entry according to policies 322 configured in the operator's network. Signaling exchanged between 323 the MAG and the LMA (PUB, PBA) needs to be extended to configure the 324 MN (via RS/RA or DHCP) to use the weak host model on a specific 325 interface. As an example according to RFC 5175 [RFC5175] a bit can 326 be assigned in the RA message indicating such option. The access 327 provider could then decide to configure the MAGs to advertise the MN 328 for weak model configuration. Obviously, understanding a new RA/RS 329 bit or a DHCP option would require new functionality in the MN`s IP 330 stack, or at minimum some kind of a networking configuration manager 331 running in a MIF node. 333 4.2. LMA considerations 335 The LMA MUST be able to identify all the mobility bindings at its 336 Binding Cache (BC) that refer to the same MN, using the MN- 337 identifier. The LMA SHOULD have an additional policy/routing table. 338 This table is used by the LMA to store and look up information about 339 how to route packets to a certain MN. With current PMIPv6 340 specification, the LMA decides on the next hop towards a particular 341 MN based only on the destination prefix (that would result on an 342 outgoing tunnel interface to reach the MAG where that prefix is 343 currently reachable). In order to allow the LMA to dynamically 344 decide which is the best path for a certain traffic to reach the MN, 345 a policy/routing table SHOULD be used. By using this table, the LMA 346 would be able to send different flows addressed to the same 347 destination IP address (e.g. pref1::if1) via different MAGs. 349 4.3. MAG considerations 351 The MAG MUST support routing packets addressed to MNs locally 352 attached to the MAG, but using a destination prefix or address that 353 is not on-link. In order to do that, the MAG SHOULD be informed by 354 the LMA about the set of IP addresses that the MN has acquired from 355 the PMIPv6 domain, so the MAG can add the required entries on its 356 routing table. The PBA MAY be extended to include such information. 357 The prefixes advertised in the Router Advertisement (RA) sent from 358 the MAG to the MN include only those that would be advertised in case 359 of base RFC 5213 operation without any flow/policy routing 360 extensions. 362 4.4. Downlink and Uplink considerations 364 The extensions outlined in this document would allow an MN to 365 simultaneously receive traffic through all of its interfaces that are 366 attached to the same PMIPv6 domain. Enabling such a feature in the 367 Downlink (DL) makes sense when several access networks are available 368 at the same time, as for example in heterogeneous PMIPv6 domains 369 where several access technologies exhibiting different DL capacities 370 are found (e.g., WLAN and 3G). 372 Enabling the feature on the Uplink (UL) is also possible. Enabling 373 the network (i.e., the LMA) to have the control on which MN's 374 outgoing interface it used for a certain flow requires changes on the 375 MN side, as well as signaling on the MN-AR interface or configuring 376 explicit routes on the MN using existing host configuration protocols 377 at IP level (e.g. DHCP). Nevertheless, if the decision is on the MN 378 side, this might be easily supported by the solution outlined in this 379 document, by properly configuring the routing and ingress filtering 380 at the MAGs. 382 The mapping of a flow to an interface may be driven by the terminal, 383 the LMA or both: 385 1. driven by the terminal: the terminal establishes the policy and 386 selects the interface to send packets. The LMA must be aware of 387 the flow/interface mapping policy to keep consistency in routing 388 (the terminal would expect receiving traffic on a specific 389 interface). So the terminal may provide its policy to the LMA. 391 2. driven by the LMA: the LMA have the control on which MN's 392 outgoing interface is used for a certain flow. In such a case 393 the MN's routing table is updated according to the policy which 394 must be provided to the MN by the LMA. 396 3. MN driven but assisted by the LMA: the terminal controls the 397 mapping of the flows to the possible interfaces. However the LMA 398 provides some default policies which can be updated by the MN. 399 The policies must be exchanged in both directions (from LMA to MN 400 and vice versa). 402 4.5. IPv4 considerations 404 IPv4 Home Addresses work mostly in a similar manner as IPv6 HNPs in 405 the context of PMIPv6 and MIF nodes. Though, a MIF node may by 406 default apply a different host model depending on the IP version. 408 One problem with IPv4 Home Addresses is the possible use of private 409 IPv4 addresses [RFC1918]. It is possible for a MIF node to configure 410 overlapping public IPv4 Addresses on multiple interfaces. This is 411 not a new issue as it has been possible since the introduction of 412 [RFC1918] and any multi-homed IPv4 node. Still, the host operation 413 is not generally clearly defined in case of multiple overlapping 414 addresses. The only common advice is to avoid overlapping [RFC1918] 415 private IPv4 Home Addresses within PMIPv6 domain, unless the MIF 416 nodes are known to be able to handle such situation gracefully. This 417 situation resembles the scenario iii) of 418 [I-D.devarapalli-netext-multi-interface-support] and therefore is out 419 of scope of this document. 421 5. Implementation Experience 423 In this section we report on early implementation experience under 424 Linux OS from a testbed running the solution proposed in this 425 document. 427 5.1. Test setup 429 The test-bed is made up of 5 PCs connected according to the scheme of 430 Figure 4 actually the MN's NICs in use are two WLAN cards, and the 431 routes and policies refer to an already established multihoming 432 scenario). 434 +-----+ 435 | C N | 436 +-----+ 437 | LMA Binding Cache LMA policy/routing table 438 | ===================== ============================ 439 | MN:if1, pref1, MAG1 flow1(6-tuple1)->MAG2 440 +-----+ :if2, pref2, MAG2 flow2(6-tuple2)->MAG2 441 | LMA | ... 442 +-----+ flowN(6-tupleN)->MAG1 443 //\\ 444 +---------//--\\-------------+ 445 ( // \\ ) PMIPv6 domain 446 ( // \\ ) 447 +------//--------\\----------+ 448 // \\ 449 // \\ MAG2 routing table 450 +----+ +----+ ================================ 451 |MAG1| |MAG2| (dest) (next hop) 452 +----+ +----+ pref2::/64 directly connected 453 | | pref1::/64 pref2::if2 454 | | 455 | pref1 pref2 | 456 | if1 if2 | 457 +-------[MN]------+ MN implements the weak host model 458 (WLAN) (3G) 460 Figure 4: Test setup 462 5.2. Attachment phase 464 5.2.1. MAG considerations 466 Upon receiving an RS from the MN, the MAG checks whether the MN is 467 proxy authorized and consequently runs for authentication. This 468 procedure is replicated by means of a static configuration file that 469 also maps the MN's set of MAC addresses into a unique MN-ID and 470 provides a Multi-homing request indication. As described in 471 Section 4.2, the LMA MUST be able to identify all the mobility 472 bindings at its Binding Cache (BC) that refer to the same MN, using 473 the MN-ID, and this is ensured by filling the PBU's MN-ID and 474 MN-LL-ID options respectively with the MN-ID and MAC address 475 specified in the config file. 477 One extra option, called MuHo option, is added in the PBU if the 478 config file specifies a multi-homing request. The option format 479 coincides with the Home Network Prefix Option specified in section 480 8.3 of RFC 5213, but for the option type number, that has to be 481 agreed on (the MuHo option will be fully specified in a subsequent 482 version of this document). The MAG sends an empty option, indicating 483 that the MN has MuHo capabilities. By means of this option, the MAG 484 is requesting all the prefixes that might have been assigned to other 485 interfaces of the same MN. These prefixes are then obtained by 486 looking for the same option in the PBA message. One option is used 487 for each prefix and multiple options may be present if the MN has 488 already two or more interfaces attached. Once the MAG gains these 489 prefixes it's able to set up downlink and uplink routes for all the 490 MN's interfaces via the the one that's attempting to attach. 492 5.2.2. LMA considerations 494 Once the PBU is received by the LMA, if the MuHo option is present, 495 is then processed to look if the registration might be related to 496 other BCEs that belong to the same MN. The LMA stores an extra data 497 structure which entries contain pointers to group together all the 498 BCEs that share the same MN-ID. Every BCE will also have a pointer 499 to its correspondent MuHo entry. In such a way, when retrieving a 500 BCE by looking for a prefix, the LMA is able to find quickly all the 501 prefixes assigned to the interfaces that are already connected to the 502 domain. If the lookup succeeds, the LMA sends a PBA message with one 503 MuHo option for each prefix, otherwise it replies with an empty 504 option. 506 5.2.3. Miscellaneous considerations 508 Multiple attachments procedure should work as follows. Every time 509 that the MN attaches a new interface via a new MAG the LMA updates 510 its binding cache accordingly. The LMA should further notify all the 511 previous MAGs about the configured HNPs. To this end the LMA can re- 512 use the binding revocation mechanism to notify the MN that PMIP 513 multi-homing service has been updated. This allows the LMA to 514 propagates all the HNPs across multiple MAGs. 516 5.3. Flow Management 518 The test is intended to let the flows be driven only by the LMA, i.e. 519 by the network side. Throughout the following considerations a flow 520 is then intended to come from outside the PMIP domain and addressed 521 to the MN regardless of the nature nor content of the stream itself. 523 Every packet that passes through the LMA has to be inspected in order 524 to be assigned to a particular flow and then routed according to a 525 flow-policy. Flow management is therefore divided into two steps: 527 1. Identification of the flows; 528 2. Routing of the flows; 530 Netfilter API and ip6tables can be used to accomplish both tasks. 531 Netfilter provides 5 hooks in the routing scheme where a packet can 532 be manipulated or made available for user-space applications 533 (PREROUTING, INPUT, OUTPUT, FORWARDING and POSTROUTING in Figure 5). 535 | Incoming Packet 536 | 537 | 538 +-----+------+ 539 | PREROUTING | 540 +-----+------+ 541 | 542 +-------+ +----+----+ 543 | INPUT +------+ routing +--------+ 544 +---+---+ +---------+ | 545 | | 546 +-------+-------+ +----+----+ 547 | local process | | FORWARD | 548 +-------+-------+ +----+----+ 549 | | 550 +----+---+ +---------+ | 551 | OUTPUT +------+ routing +--------+ 552 +--------+ +----+----+ 553 | 554 +------+------+ 555 | POSTROUTING | 556 +------+------+ 557 | 558 | Outgoing Packet 560 Figure 5: Flow management 562 5.3.1. Flow identification 564 Using PREROUTING hook and NFQUEUE policy, ip6tables passes packets to 565 a user-space application that performs both tasks mentioned before 566 and is detached from the genuine LMA implementation. Once the packet 567 is made available to user-space, the first operation consists in 568 extracting the following parameters from it: 570 o source address; 572 o destination address; 573 o source port; 575 o destination port; 577 o IPv6 flow label; 579 o L4 protocol type. 581 Each flow is singled out by this tuple of parameters and the tuple is 582 mapped into a flow identifier that univocally identifies the stream. 583 A data structure stores the active flows and the associated 584 identifiers, so, as second operation, a lookup over the active flows 585 is performed. Then any packet can alternatively be assigned into an 586 already existing flow, or trigger a new flow generation. 588 Before the packets leave user-space, the last process' operation is 589 appending a mark containing the associated flow-ID. The mark does 590 not modify the packet's content and it is automatically removed by 591 netfilter when the packet leaves the routing scheme in figure. Even 592 if multiple connections are set up between the same end-points (i.e. 593 the same couple of destination/source addresses), different flows 594 still remain distinguishable (and therefore managed) as far as one of 595 the above parameters changes. 597 5.3.2. Flow routing 599 Linux kernel is able to manage up to 256 different routing tables, 600 that may contain contrasting routes. When a packet has to be routed, 601 usually table 254 (or MAIN) is inspected, but routing rules can be 602 added to decide which is the most suitable table for a given packet. 604 As an example, rules are used to perform source-based routing, since 605 a rule can specify a certain routing table for all the packets that 606 match a given source address. This is the "from" rule-type. Source 607 routing is applied in the MAGs, because every packet coming from the 608 MN must be forwarded through the tunnel. 610 On the LMA we use the "fwmark" rule-type, instead of the "from" rule- 611 type in the manner explained below. This rule-type forces to inspect 612 a given table if the packet matches the mark that is appended by the 613 user-space netfilter-based process described before. A table is then 614 created for each existing tunnel with just one route that forces to 615 use that tunnel for all destinations, and this table is pointed to by 616 a set of rules looking for different marks. Since every packet is 617 inspected and marked, at this point it is possible to route them 618 according to a given routing table, and therefore forwarded through a 619 desired tunnel, by switching the table the rule points to. 621 5.4. Extensions on the MN 623 It was implicitly assumed that a CN outside (or not) the PMIP domain 624 only knows the MN's address that was first acquired by the MN itself. 625 This assumption, in addition to all considerations made in this 626 document, gives consistency to the test as far as we consider the MN 627 to have one public address/interface and a bunch of private 628 addresses/interfaces. In such way, a flow (whether the connection 629 was started by the MN or not) will always be first transmitted over 630 the public interface and then eventually moved upon a LMA decision 631 (this also provides a weak tolerance towards the full multi-homing 632 issue mentioned in Section 5.2.3). 634 Anyway, it's always possible to use in downlink a desired MN's 635 interface since the MN behaves as weak host. For the uplink, whether 636 the connection is started by a local or a remote process, the MN will 637 transmit through the interface that guarantees to reach the 638 destination by means of a default or specific route. If the 639 connection is started by the CN then the answers will carry as source 640 the address specified in the incoming packet's destination, otherwise 641 the packets will have as source the address assigned to the 642 transmitting interface. In no case the MN can start a connection 643 through an interface carrying the address of another interface. 645 It would thus be possible to provide a method to add, delete or 646 change a per-host route whenever we would like to switch interface 647 for a given connection. 649 The lacks of this solution resides in: 651 o the impossibility to manage multiple connections over different 652 interfaces between the same end-points (i.e. the same couple of 653 source/destination addresses); 655 o starting a connection with an undesired address. This problem 656 could be overcame by using the netfilter-based application in the 657 MN too, in such a way to either "reflect" packets through the same 658 interface that received the flow those packets belong to (if the 659 connection was started remotely), or force the application-layer 660 processes to choose the source address according to table MAIN but 661 then actually route packets inspecting another routing table (if 662 the connection is started by the MN). 664 A different approach is adopted when using a virtual interface. 665 Linux kernel provides a module called "bonding" to group together 666 several interfaces (or "slaves", in the module's terminology) that 667 will have the same L2 and L3 address and figure out to be as just one 668 interface. The module offers the possibility to select the 669 transmitting slave according to pre-configured policies. 670 Unfortunately these policies do not cover the scope of flow 671 management so the module has to be extended to allow an external 672 input to select the transmitting slave. 674 As second configuration we suppose the MN to use a virtual interface, 675 so that each interface will have the same MAC address and the same 676 prefix will be assigned. In this case the LMA will store the same 677 BCE for all the interfaces, and conflicts may arise. Indeed, when 678 the LMA receives a PBU from a MAG for a Proxy Registration, it may 679 find that the BCE already exists with a different CoA, as that CoA is 680 the address of the MAG to which another interface of the same MN is 681 attached. This may be interpreted as an unexpected handover if the 682 handoff indicator field is not properly set. The Access Technology 683 Type in conjunction with a new value of the HI field in the PBU might 684 be used to avoid conflicts in the registration. The correct behavior 685 for the LMA would lead to a new tunnel creation in order to allow the 686 MN to be reached via all the MAGs to which the MN's interfaces are 687 attached. That's why the BCE format must be extended too to contain 688 multiple CoAs and tunnel identifiers. 690 6. IANA Considerations 692 MuHo option, TBD. 694 7. Security Considerations 696 None. 698 8. Acknowledgements 700 The authors would like to thank Fabio Giust for his work on the 701 implementation of the mechanism described on this document. 703 The authors would like to thank Paulo Ferrer and Marco Liebsch for 704 their comments and discussion on this document. 706 The research of Carlos J. Bernardos leading to these results has 707 received funding from the European Community's Seventh Framework 708 Programme (FP7/2007-2013) under grant agreement n. 214994 (CARMEN 709 project) and also from the Ministry of Science and Innovation of 710 Spain, under the QUARTET project (TIN2009-13992-C02-01). 712 9. References 713 9.1. Normative References 715 [RFC1122] Braden, R., "Requirements for Internet Hosts - 716 Communication Layers", STD 3, RFC 1122, October 1989. 718 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 719 E. Lear, "Address Allocation for Private Internets", 720 BCP 5, RFC 1918, February 1996. 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement 726 Flags Option", RFC 5175, March 2008. 728 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 729 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 731 9.2. Informative References 733 [I-D.devarapalli-netext-multi-interface-support] 734 Devarapalli, V., Kant, N., Lim, H., and C. Vogt, "Multiple 735 Interface Support with Proxy Mobile IPv6", 736 draft-devarapalli-netext-multi-interface-support-00 (work 737 in progress), March 2009. 739 [I-D.ietf-mif-current-practices] 740 Wasserman, M., "Current Practices for Multiple Interface 741 Hosts", draft-ietf-mif-current-practices-00 (work in 742 progress), October 2009. 744 [I-D.ietf-mif-problem-statement] 745 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 746 Statement", draft-ietf-mif-problem-statement-01 (work in 747 progress), October 2009. 749 [I-D.ietf-netlmm-pmip6-ipv4-support] 750 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 751 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-18 752 (work in progress), February 2010. 754 [I-D.jeyatharan-netext-multihoming-ps] 755 Jeyatharan, M. and C. Ng, "Multihoming Problem Statement 756 in NetLMM", draft-jeyatharan-netext-multihoming-ps-01 757 (work in progress), March 2009. 759 [I-D.thaler-ip-model-evolution] 760 Thaler, D., "Evolution of the IP Model", 761 draft-thaler-ip-model-evolution-01 (work in progress), 762 July 2008. 764 Authors' Addresses 766 Carlos J. Bernardos 767 Universidad Carlos III de Madrid 768 Av. Universidad, 30 769 Leganes, Madrid 28911 770 Spain 772 Phone: +34 91624 6236 773 Email: cjbc@it.uc3m.es 774 URI: http://www.it.uc3m.es/cjbc/ 776 Telemaco Melia 777 Alcatel-Lucent Bell Labs 779 Email: Telemaco.Melia@alcatel-lucent.com 781 Pierrick Seite 782 France Telecom 784 Email: pierrick.seite@orange-ftgroup.com 786 Jouni Korhonen 787 Nokia Siemens Networks 789 Email: jouni.korhonen@nsn.com