idnits 2.17.1 draft-boucadair-mptcp-plain-mode-04.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 : ---------------------------------------------------------------------------- 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 (November 5, 2015) is 3092 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-08) exists of draft-boucadair-mptcp-dhc-01 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcp-edo-04 == Outdated reference: A later version (-12) exists of draft-touch-tcpm-tcp-syn-ext-opt-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental France Telecom 5 Expires: May 8, 2016 D. Behaghel 6 OneAccess 7 S. Secci 8 Universite Pierre et Marie Curie (UPMC) 9 November 5, 2015 11 An MPTCP Option for Network-Assisted MPTCP Deployments: Plain Transport 12 Mode 13 draft-boucadair-mptcp-plain-mode-04 15 Abstract 17 One of the promising deployment scenarios for Multipath TCP (MPTCP) 18 is to enable a Customer Premises Equipment (CPE) that is connected to 19 multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its 20 network attachments. Because of the lack of MPTCP support at the 21 server side, some service providers now consider a network-assisted 22 model that relies upon the activation of a dedicated function called 23 MPTCP Concentrator. This document focuses on a deployment scheme 24 where the identity of the MPTCP Concentrator(s) is explicitly 25 configured on connected hosts. 27 This document specifies an MPTCP option that is used to avoid an 28 encapsulation scheme between the CPE and the MPTCP Concentrator. 29 Also, this document specifies how UDP traffic can be distributed 30 among available paths without requiring any encapsulation scheme. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on May 8, 2016. 55 Copyright Notice 57 Copyright (c) 2015 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 4. Introducing the MPTCP Plain Transport Mode . . . . . . . . . 5 76 4.1. An Alternative to Encapsulation . . . . . . . . . . . . . 5 77 4.2. Plain Mode MPTCP Option . . . . . . . . . . . . . . . . . 6 78 4.3. Theory of Operation . . . . . . . . . . . . . . . . . . . 7 79 4.4. Flow Example . . . . . . . . . . . . . . . . . . . . . . 8 80 5. UDP Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 9.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 One of the promising deployment scenarios for Multipath TCP (MPTCP, 92 [RFC6824]) is to enable a Customer Premises Equipment (CPE) that is 93 connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the 94 usage of such resources, see for example [I-D.deng-mptcp-proxy] or 95 [RFC4908]. This deployment scenario relies on MPTCP proxies located 96 on both the CPE and network sides (Figure 1). The latter plays the 97 role of traffic concentrator. A concentrator terminates the MPTCP 98 sessions established from a CPE, before redirecting traffic into a 99 legacy TCP session. 101 IP Network #1 102 +------------+ _--------_ +------------+ 103 | | (e.g., LTE ) | | 104 | CPE +=======+ +===+ | 105 | (MPTCP | (_ _) |Concentrator| 106 | Proxy) | (_______) | (MPTCP | 107 | | | Proxy) |------> Internet 108 | | | | 109 | | IP Network #2 | | 110 | | _--------_ | | 111 | | ( e.g., DSL ) | | 112 | +=======+ +==+ | 113 | | (_ _) | | 114 +-----+------+ (_______) +------------+ 115 | 116 ----CPE network---- 117 | 118 end-nodes 120 Figure 1: "Network-Assisted" MPTCP Design 122 Both implicit and explicit models are considered to steer traffic 123 towards an MPTCP Concentrator. This document focuses on the explicit 124 model that consists in configuring explicitly the reachability 125 information of the MPTCP concentrator on a host (e.g., 126 [I-D.boucadair-mptcp-dhc]). 128 This specification assumes an MPTCP Concentrator is reachable through 129 one or multiple IP addresses. Also, it assumes the various network 130 attachments provided to an MPTCP-enabled CPE are managed by the same 131 administrative entity. Additional assumptions are listed in 132 Section 3. 134 This document explains how a plain transport mode, where packets are 135 exchanged between the CPE and the concentrator without requiring the 136 activation of any encapsulation scheme (e.g., IP-in-IP [RFC2473], GRE 137 [RFC1701], SOCKS [RFC1928], etc.), can be enabled. 139 Also, this document investigates an alternate track where UDP flows 140 can be distributed among available paths without requiring any 141 encapsulation scheme. 143 The solution in this document does not require the modification of 144 the binding information base (BIB) structure maintained by both the 145 CPE and the Concentrator. Likewise, this approach does not infer any 146 modification of the Network Address Translator (NAT) functions that 147 may reside in both the CPE and the device that embeds the 148 concentrator. 150 The solution also works properly when NATs are present in the network 151 between the CPE and the Concentrator, unlike solutions that rely upon 152 GRE tunneling. Likewise, the solution accommodates deployments that 153 involve CGN (Carrier Grade NAT) upstream the Concentrator. 155 2. Terminology 157 This document makes use of the following terms: 159 o Customer-facing interface: is an interface of the MPTCP 160 Concentrator that is visible to a CPE and which is used for 161 communication purposes between a CPE and the MPTCP Concentrator. 163 o MPTCP Proxy: is a software module that is responsible for 164 transforming a TCP connection into an MPTCP connection, and vice 165 versa. Typically, an MPTCP proxy can be embedded in a CPE and/or 166 a Concentrator. 168 o MPTCP leg: Refers to a network segment on which MPTCP is used to 169 establish TCP connections. 171 o MPTCP Concentrator (or concentrator): refers to a functional 172 element that is responsible for aggregating the traffic of a group 173 of CPEs. This element is located upstream in the network. One or 174 multiple concentrators can be deployed in the network side to 175 assist MPTCP-enabled CPEs to establish MPTCP connections via 176 available network attachments. 178 On the uplink path, the concentrator terminates the MPTCP 179 connections received from its customer-facing interfaces and 180 transforms these connections into legacy TCP connections towards 181 upstream servers. 183 On the downlink path, the concentrator turns the legacy server's 184 TCP connection into MPTCP connections towards its customer-facing 185 interfaces. 187 3. Assumptions 189 The following assumptions are made: 191 o The logic for mounting network attachments by a host is 192 deployment- and implementation-specific and is out of scope of 193 this document. 194 o The Network Provider that manages the various network attachments 195 (including the concentrators) can enforce authentication and 196 authorization policies using appropriate mechanisms that are out 197 of scope of this document. 198 o Policies can be enforced by a concentrator instance operated by 199 the Network Provider to manage both upstream and downstream 200 traffic. These policies may be subscriber-specific, connection- 201 specific or system-wide. 202 o The concentrator may be notified about the results of monitoring 203 (including probing) the various network legs to service a 204 customer, a group of customers, a given region, etc. No 205 assumption is made by this document about how these monitoring 206 (including probing) operations are executed. 207 o An MPTCP-enabled, multi-interfaced host that is directly connected 208 to one or multiple access networks is allocated addresses/prefixes 209 via legacy mechanisms (e.g., DHCP) supported by the various 210 available network attachments. The host may be assigned the same 211 or distinct IP address/prefix via the various available network 212 attachments. 213 o The location of the concentrator(s) is deployment-specific. 214 Network Providers may choose to adopt centralized or distributed 215 (even if they may not be present on the different network 216 accesses) designs, etc. Nevertheless, in order to take advantage 217 of MPTCP, the location of the concentrator should not jeopardize 218 packet forwarding performance for traffic sent from or directed to 219 connected hosts. 221 4. Introducing the MPTCP Plain Transport Mode 223 4.1. An Alternative to Encapsulation 225 The design option for aggregating various network accesses often 226 relies upon the use of an encapsulation scheme (such as GRE) between 227 the CPE and the Concentrator. The use of encapsulation is motivated 228 by the need to steer traffic through the concentrator and also to 229 allow the distribution of UDP flows among the available paths without 230 requiring any advanced traffic engineering tweaking technique in the 231 network side to intercept traffic and redirect it towards the 232 appropriate concentrator. 234 This document specifies another approach that relies upon plain 235 transport mode between the CPE and the Concentrator. 237 The use of a plain transport mode does not require the upgrade of any 238 intermediate function (security, TCP optimizer, etc.) that may be 239 located on-path. Thus, the introduction of MPTCP concentrators in 240 operational networks to operate plain mode does not add any extra 241 complexity as far as the operation of possible intermediate functions 242 is concerned. 244 4.2. Plain Mode MPTCP Option 246 The format of the Plain Mode MPTCP option is shown in Figure 2. 248 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 249 +---------------+---------------+-------+-------+---------------+ 250 | Kind | Length |SubType|D|U| Flag Bits | 251 +---------------+---------------+-------+-------+---------------+ 252 | Address (IPv4 - 4 octets / IPv6 - 16 octets) | 253 +-------------------------------+-------------------------------+ 254 | Port (2 octets, optional) | 255 +-------------------------------+ 257 Figure 2: Plain Mode MPTCP Option 259 The description of the fields is as follows: 261 o Kind and Length: are the same as in [RFC6824]. 263 o Subtype: to be defined by IANA (Section 6). 265 o D-bit (direction bit): This flag indicates whether the enclosed IP 266 address (and a port number) reflects the source or destination IP 267 address (and port). When the D-bit is set, the enclosed IP 268 address must be interpreted as the source IP address. When the 269 D-bit is unset, the enclosed IP address must be interpreted as the 270 destination IP address. 272 o U-bit (UDP bit): The use of this flag is detailed in Section 5. 274 o The "Flag" bits are reserved bits for future assignment as 275 additional flag bits. These additional flag bits MUST each be set 276 to zero and MUST be ignored upon receipt. 278 o Address: Includes a source or destination IP address. The address 279 family is determined by the "Length" field. 281 o Port: May be used to carry a port number. 283 4.3. Theory of Operation 285 Plain mode operation is as follows: 287 (1) The CPE is provisioned with the reachability information of one 288 or several Concentrators (e.g., [I-D.boucadair-mptcp-dhc]). 290 (2) Outgoing TCP packets that can be forwarded by a CPE along MPTCP 291 subflows are transformed into TCP packets carried over a MPTCP 292 connection. The decision-making process to decide whether a 293 flow should be MPTCP-tagged or not is local to the Concentrator 294 and the CPE. It depends on the policies provisioned by the 295 network provider. As such, the decision-making process is 296 policy-driven, implementation- and deployment-specific. 298 (3) MPTCP packets are sent using a plain transport mode (i.e., 299 without any encapsulation header). 301 The source IP address and source port number are those assigned 302 locally by the CPE. Because multiple IP addresses may be 303 available to the CPE, the address used to rewrite the source IP 304 address for an outgoing packet forwarded through a given network 305 attachment (typically, a WAN interface) MUST be associated with 306 that network attachment. It is assumed that ingress filtering 307 ([RFC2827]) is implemented at the boundaries of the networks to 308 prevent any spoofing attack. 310 The destination IP address is replaced by the CPE with one of 311 the IP addresses of the Concentrator. 313 The destination port number may be maintained as initially set 314 by the host or altered by the CPE. 316 The original destination IP address is copied into a dedicated 317 MPTCP option called Plain Mode MPTCP option (see Section 4.2). 318 Because of the limited TCP option space, it is RECOMMENDED to 319 implement the solution specified in [I-D.ietf-tcpm-tcp-edo]. As 320 a reminder, [I-D.touch-tcpm-tcp-syn-ext-opt] specifies a 321 proposal for TCP SYN extended option space. 323 A binding entry must be maintained by the CPE for that outgoing 324 packet. This binding entry is instantiated by the NAT and/or 325 the firewall functions embedded in the CPE. 327 (4) Upon receipt of the packet on the MPTCP leg, the Concentrator 328 extracts the IP address included in the Plain Mode MPTCP Option 329 that it uses as the destination IP address of the packet 330 generated in the TCP leg towards its ultimate destination. 332 The source IP address and port are those of the Concentrators. 333 A binding entry is instantiated by the Concentrator to record 334 the state. 336 The concentrator may be configured to behave as either a 1:1 337 address translator or a N:1 translator where the same address is 338 shared among multiple CPEs. Network Providers should be aware 339 of the complications that may arise if a given IP address/prefix 340 is shared among multiple hosts (see [RFC6967]). Whether these 341 complications apply or not is deployment-specific. 343 The Concentrator should preserve the same IP address that was 344 assigned to a given CPE for all its outgoing connections when 345 transforming an MPTCP connection into a TCP connection. 347 (5) For incoming TCP packets that need to be forwarded to a CPE, the 348 Concentrator records the source IP address in a Plain Mode MPTCP 349 Option. 351 The source IP address is replaced with one of the IP addresses 352 listed in the aforementioned binding information base maintained 353 by the Concentrator (if such a state entry exists) or with one 354 of the Concentrator's IP addresses. 356 The destination IP address is replaced with the CPE's IP address 357 (if the corresponding state entry is found in the Concentrator's 358 binding table) or with one of the CPE's IP addresses (that are 359 known by the concentrator using some means that are out of the 360 scope of the document). 362 4.4. Flow Example 364 A typical flow exchange is shown in Figure 3. 366 This example assumes no NAT is located between the CPE and the 367 concentrator. 369 Because the remote server is not MPTCP-aware, the Concentrator is 370 responsible for preserving the same IP address (conc_@, in the 371 example) for the same CPE even if distinct IP addresses (cpe_@1 and 372 cpe_@2, in the example) are used by the CPE to establish subflows 373 with the Concentrator. 375 +-------+ 376 |DNS | 377 +--------+ |System | +------------+ 378 | CPE | +-------+ |Concentrator| 379 +--------+ | +------------+ 380 | | | 381 DNS | | | 382 -------->| DNS Query | | 383 Query |------------------------->| | 384 | DNS Reply | | 385 |<-------------------------| | 386 | | 387 | | 388 src=s_@|src=cpe_@1 dst=conc_@1|src=conc_@ 389 -------->|--------Plain Mode MPTCP Option(d_@)--------->|--------> 390 dst=d_@| |dst=d_@ 391 .... 393 | | 394 src=d_@|dst=cpe_@1 src=conc_@1|src=d_@ 395 <--------|<-------Plain Mode MPTCP Option(d_@)----------|<------- 396 dst=s_@| |dst=conc_@ 397 .... 399 src=s_@|src=cpe_@2 dst=conc_@1|src=conc_@ 400 -------->|--------Plain Mode MPTCP Option(d_@)--------->|--------> 401 dst=d_@| |dst=d_@ 402 .... 404 Legend: 405 * "--Plain Mode MPTCP Option()->" indicates the packet is sent 406 in a plain mode, i.e., without any encapsulation hander, 407 and that "Plain Mode MPTCP Option" is carried in the packet. 409 Figure 3: Flow Example: No NAT between the CPE and the Concentrator 411 5. UDP Traffic 413 From an application standpoint, there may be a value to distribute 414 UDP datagrams among available network attachments for the sake of 415 network resource optimisation, for example. 417 Unlike existing proposals that rely upon encapsulation schemes such 418 as IP-in-IP or GRE, this document suggests the use of MPTCP features 419 to control how UDP datagrams are distributed among existing network 420 attachments. UDP datagrams are therefore transformed into TCP- 421 formatted packets. 423 The CPE and the Concentrator MUST establish a set of subflows that 424 are maintained alive. These subflows are used to transport UDP 425 datagrams that are distributed among existent subflows. TCP session 426 tracking is not enabled for the set of subflows that are dedicated to 427 transport UDP traffic. The establishment of these subflows is not 428 conditioned by the receipt of UDP packets; instead, these subflows 429 are initiated upon CPE reboot or when network conditions change 430 (e.g., whenever a new Concentrator is discovered or a new IP address 431 is assigned to the Concentrator). 433 When the CPE (or the Concentrator) transforms a UDP packet into a TCP 434 one, it MUST insert the Plain Mode MPTCP Option with the U-bit set. 435 When setting the source IP address, the destination IP address, and 436 the IP address enclosed in the Plain Mode MPTCP Option, the same 437 considerations specified in Section 4.3 MUST be followed. 439 In addition, the CPE (or the Concentrator) MUST replace the UDP 440 header with a TCP header. Upon receipt of the packet with the U-bit 441 set, the Concentrator (or the CPE) transforms the packet into a UDP 442 packet and follows the same considerations specified in Section 4.3. 443 Both the CPE and the Concentrator MAY be configured to disable some 444 features (e.g., reordering). Enabling these features is deployment 445 and implementation-specific. 447 Relaying UDP packets is not conditioned by TCP session establishment 448 because the required subflows that are dedicated to transport UDP 449 traffic are already in place (either at the CPE or the Concentrator). 451 A flow example is shown in Figure 4. 453 +--------+ +------------+ 454 | CPE | |Concentrator| 455 +--------+ +------------+ 456 | /------------------------------------------\ | 457 || Dedicated MPTCP SubFlows for UDP || 458 | \------------------------------------------/ | 459 | | 460 src=s_@|src=cpe_@1 dst=conc_@1|src=conc_@ 461 ---UDP-->|--------Plain Mode MPTCP Option(U,d_@)------->|---UDP--> 462 dst=d_@| |dst=d_@ 463 .... 464 src=s_@|src=cpe_@2 dst=conc_@2|src=conc_@ 465 ---UDP-->|--------Plain Mode MPTCP Option(U,d_@)------->|---UDP--> 466 dst=d_@| |dst=d_@ 467 | | 468 .... 469 src=s_@|src=cpe_@1 dst=conc_@1|src=conc_@ 470 ---UDP-->|--------Plain Mode MPTCP Option(U,d1_@)------>|---UDP--> 471 dst=d1_@| |dst=d1_@ 472 | | 473 src=s_@|src=cpe_@1 dst=conc_@2|src=conc_@ 474 ---UDP-->|--------Plain Mode MPTCP Option(U,d1_@)------>|---UDP--> 475 dst=d1_@| |dst=d1_@ 477 Figure 4: Distributing UDP packets over multiple connections 479 6. IANA Considerations 481 This document requests an MPTCP subtype code for this option: 483 o Plain Mode MPTCP Option 485 7. Security Considerations 487 The concentrator may have access to privacy-related information 488 (e.g., IMSI, link identifier, subscriber credentials, etc.). The 489 concentrator must not leak such sensitive information outside a local 490 domain. 492 Means to protect the MPTCP concentrator against Denial-of-Service 493 (DoS) attacks must be enabled. Such means include the enforcement of 494 ingress filtering policies at the boundaries of the network. In 495 order to prevent exhausting the resources of the concentrator by 496 creating an aggressive number of simultaneous subflows for each MPTCP 497 connection, the administrator should limit the number of allowed 498 subflows per host for a given connection. 500 Attacks outside the domain can be prevented if ingress filtering is 501 enforced. Nevertheless, attacks from within the network between a 502 host and a concentrator instance are yet another actual threat. 503 Means to ensure that illegitimate nodes cannot connect to a network 504 should be implemented. 506 Traffic theft is also a risk if an illegitimate concentrator is 507 inserted in the path. Indeed, inserting an illegitimate concentrator 508 in the forwarding path allows to intercept traffic and can therefore 509 provide access to sensitive data issued by or destined to a host. To 510 mitigate this threat, secure means to discover a concentrator (for 511 non-transparent modes) should be enabled. 513 8. Acknowledgements 515 Many thanks to Chi Dung Phung and Mingui Zhang for the comments. 517 9. References 519 9.1. Normative References 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, 523 DOI 10.17487/RFC2119, March 1997, 524 . 526 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 527 "TCP Extensions for Multipath Operation with Multiple 528 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 529 . 531 9.2. Informative References 533 [I-D.boucadair-mptcp-dhc] 534 Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options 535 for Network-Assisted Multipath TCP (MPTCP)", draft- 536 boucadair-mptcp-dhc-01 (work in progress), July 2015. 538 [I-D.deng-mptcp-proxy] 539 Lingli, D., Liu, D., Sun, T., Boucadair, M., and G. 540 Cauchie, "Use-cases and Requirements for MPTCP Proxy in 541 ISP Networks", draft-deng-mptcp-proxy-01 (work in 542 progress), October 2014. 544 [I-D.ietf-tcpm-tcp-edo] 545 Touch, J. and W. Eddy, "TCP Extended Data Offset Option", 546 draft-ietf-tcpm-tcp-edo-04 (work in progress), November 547 2015. 549 [I-D.touch-tcpm-tcp-syn-ext-opt] 550 Touch, J. and T. Faber, "TCP SYN Extended Option Space 551 Using an Out-of-Band Segment", draft-touch-tcpm-tcp-syn- 552 ext-opt-03 (work in progress), October 2015. 554 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 555 Routing Encapsulation (GRE)", RFC 1701, 556 DOI 10.17487/RFC1701, October 1994, 557 . 559 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 560 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 561 DOI 10.17487/RFC1928, March 1996, 562 . 564 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 565 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 566 December 1998, . 568 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 569 Defeating Denial of Service Attacks which employ IP Source 570 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 571 May 2000, . 573 [RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, 574 R., and H. Ohnishi, "Multi-homing for small scale fixed 575 network Using Mobile IP and NEMO", RFC 4908, 576 DOI 10.17487/RFC4908, June 2007, 577 . 579 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 580 "Analysis of Potential Solutions for Revealing a Host 581 Identifier (HOST_ID) in Shared Address Deployments", 582 RFC 6967, DOI 10.17487/RFC6967, June 2013, 583 . 585 Authors' Addresses 587 Mohamed Boucadair 588 France Telecom 589 Rennes 35000 590 France 592 Email: mohamed.boucadair@orange.com 593 Christian Jacquenet 594 France Telecom 595 Rennes 596 France 598 Email: christian.jacquenet@orange.com 600 Denis Behaghel 601 OneAccess 603 Email: Denis.Behaghel@oneaccess-net.com 605 Stefano Secci 606 Universite Pierre et Marie Curie (UPMC) 607 Paris 608 France 610 Email: stefano.secci@lip6.fr