idnits 2.17.1 draft-boucadair-mptcp-dhc-06.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2016) is 2711 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: Standards Track Orange 5 Expires: April 29, 2017 T. Reddy 6 Cisco 7 October 26, 2016 9 DHCP Options for Network-Assisted Multipath TCP (MPTCP) 10 draft-boucadair-mptcp-dhc-06 12 Abstract 14 Because of the lack of Multipath TCP (MPTCP) support at the server 15 side, some service providers now consider a network-assisted model 16 that relies upon the activation of a dedicated function called MPTCP 17 Conversion Point (MCP). Network-assisted MPTCP deployment models are 18 designed to facilitate the adoption of MPTCP for the establishment of 19 multi-path communications without making any assumption about the 20 support of MPTCP by the communicating peers. MCPs located in the 21 network are responsible for establishing multi-path communications on 22 behalf of endpoints, thereby taking advantage of MPTCP capabilities 23 to achieve different goals that include (but are not limited to) 24 optimization of resource usage (e.g., bandwidth aggregation), of 25 resiliency (e.g., primary/backup communication paths), and traffic 26 offload management. 28 This document focuses on the explicit deployment scheme where the 29 identity of the MPTCP Conversion Point(s) is explicitly configured on 30 connected hosts. This document specifies DHCP (IPv4 and IPv6) 31 options to configure hosts with Multipath TCP (MPTCP) parameters. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on April 29, 2017. 56 Copyright Notice 58 Copyright (c) 2016 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 Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. DHCPv6 MPTCP Option . . . . . . . . . . . . . . . . . . . . . 5 76 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 6 78 4. DHCPv4 MPTCP Option . . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 8 81 5. DHCP Server Configuration Guidelines . . . . . . . . . . . . 8 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 8.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 10 86 8.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . 10 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 10.2. Informative References . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 One of the promising deployment scenarios for Multipath TCP (MPTCP, 96 [RFC6824]) is to enable a Customer Premises Equipment (CPE) that is 97 connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the 98 usage of such resources. This deployment scenario relies on MPTCP 99 Conversion Points (MCPs) located on both the CPE and network sides 100 (Figure 1). The latter plays the role of traffic concentrator. An 101 MCP terminates the MPTCP sessions established from a CPE, before 102 redirecting traffic into a legacy TCP session. 104 +------------+ _--------_ +----------------+ 105 | | ( LTE ) | | 106 | CPE +=======+ +===+ Backbone | 107 | (MCP) | (_ _) | Network | 108 | | (_______) |+--------------+| 109 | | IP Network #1 || Concentrator ||------> Internet 110 | | || (MCP) || 111 | | |+--------------+| 112 | | IP Network #2 | | 113 | | _--------_ | | 114 | | ( DSL ) | | 115 | +=======+ +==+ | 116 | | (_ _) | | 117 +-----+------+ (_______) +----------------+ 118 | 119 ---- LAN ---- 120 | 121 end-nodes 123 Figure 1: "Network-Assisted" MPTCP Design 125 Both implicit and explicit modes are considered to steer traffic 126 towards an MPTCP Conversion Point (MCP). This document focuses on 127 the explicit mode that consists in configuring explicitly the 128 reachability information of the MCP on a host. Concretely, the 129 explicit mode has several advantages, e.g.,: 131 o It does not impose any specific constraint on the location of the 132 MCP. For example, the MCP can be located in any access network, 133 located upstream in the core network, or located in a data canter 134 facility. 136 o Tasks required for activating the explicit mode are minimal. In 137 particular, this mode does not require any specific routing and/or 138 forwarding policies for handling outbound packets other than 139 ensuring that an MCP is reachable from a CPE, and vice versa 140 (which is straightforward IP routing policy operation). 142 o The engineering effort to change the location of an MCP for some 143 reason (e.g., to better accommodate dimensioning constraints, to 144 move the MCP to a data canter, to enable additional MCP instances 145 closer to the customer premises, etc.) is minimal 147 o An operator can easily enforce strategies for differentiating the 148 treatment of MPTCP connections that are directly initiated by an 149 MPTCP-enabled host connected to an MCP if the explicit mode is 150 enabled. Typically, an operator may decide to offload MPTCP 151 connections originated by an MPTCP-enabled terminal from being 152 forwarded through a specific MCP, or decide to relay them via a 153 specific MCP. Such policies can be instructed to the MCP. 154 Implementing such differentiating behavior if the implicit mode is 155 in use may be complex to achieve. 157 o Multiple MCPs can be supported to service the same CPE, e.g., an 158 MCP can be enabled for internal services (to optimize the delivery 159 of some operator-specific services) while another MCP may be 160 solicited for external services (e.g., access to the Internet). 161 The explicit mode allows the deployment of such scenario owing to 162 the provisioning of an MCP selection policy table that relies upon 163 the destination IP prefixes to select the MCP to involve for an 164 ongoing MPTCP connection, for instance. 166 o Because the MCP's reachability information is explicitly 167 configured on the CPE, means to guarantee successful inbound 168 connections can be enabled in the CPE to dynamically discover the 169 external IP address that has been assigned for communicating with 170 remote servers, instruct the MCP to maintain active bindings so 171 that incoming packets can be successfully redirected towards the 172 appropriate CPE, etc. 174 o Troubleshooting and root cause analysis may be facilitated in the 175 explicit mode since faulty key nodes that may have caused a 176 service degradation are known. Because of the loose adherence to 177 the traffic forwarding and routing polices, troubleshooting a 178 service degradation that is specific to multi-access serviced 179 customers should first investigate the behavior of the involved 180 MCP. 182 This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options 183 that can be used to configure hosts with MCP IP addresses. 185 This specification assumes an MCP is reachable through one or 186 multiple IP addresses. As such, a list of IP addresses can be 187 returned in the DHCP MPTCP option. Also, it assumes the various 188 network attachments provided to an MPTCP-enabled CPE are managed by 189 the same administrative entity. 191 2. Terminology 193 This document makes use of the following terms: 195 o Multipath Conversion Point (MCP): a function that terminates a 196 transport flow and relays all data received over it over another 197 transport flow. This element is located upstream in the network. 198 One or multiple MCPs can be deployed in the network side to assist 199 MPTCP-enabled devices to establish MPTCP connections via available 200 network attachments. 202 On the uplink path, the MCP terminates the MPTCP connections 203 [RFC6824] received from its customer-facing interfaces and 204 transforms these connections into legacy TCP connections [RFC0793] 205 towards upstream servers. 207 On the downlink path, the MCP turns the legacy server's TCP 208 connection into MPTCP connections towards its customer-facing 209 interfaces. 210 o DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC3315]. 211 o DHCP client denotes a node that initiates requests to obtain 212 configuration parameters from one or more DHCP servers. 213 o DHCP server refers to a node that responds to requests from DHCP 214 clients. 216 3. DHCPv6 MPTCP Option 218 3.1. Format 220 The DHCPv6 MPTCP option can be used to configure a list of IPv6 221 addresses of an MCP. 223 The format of this option is shown in Figure 2. As a reminder, this 224 format follows the guidelines for creating new DHCPv6 options 225 (Section 5.1 of [RFC7227]). 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | OPTION_V6_MPTCP | Option-length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 | ipv6-address | 233 | | 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 | ipv6-address | 238 | | 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | ... | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2: DHCPv6 MPTCP option 246 The fields of the option shown in Figure 2 are as follows: 248 o Option-code: OPTION_V6_MPTCP (TBA, see Section 8.1) 249 o Option-length: Length of the 'MCP IP Address(es)' field in octets. 250 MUST be a multiple of 16. 251 o MCP IPv6 Addresses: Includes one or more IPv6 addresses [RFC4291] 252 of the MCP to be used by the MPTCP client. 254 Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) 255 are allowed to be included in this option. 257 To return more than one MCPs to the requesting DHCPv6 client, the 258 DHCPv6 server returns multiple instances of OPTION_V6_MPTCP. 260 3.2. DHCPv6 Client Behavior 262 Clients MAY request option OPTION_V6_MPTCP, as defined in [RFC3315], 263 Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. As a 264 convenience to the reader, we mention here that the client includes 265 requested option codes in the Option Request Option. 267 The DHCPv6 client MUST be prepared to receive multiple instances of 268 OPTION_V6_MPTCP; each instance is to be treated separately as it 269 corresponds to a given MCP: there are as many MCPs as instances of 270 the OPTION_V6_MPTCP option. 272 If an IPv4-mapped IPv6 address is received in OPTION_V6_MPTCP, it 273 indicates that the MCP has the corresponding IPv4 address. 275 The DHCPv6 client MUST silently discard multicast and host loopback 276 addresses [RFC6890] conveyed in OPTION_V6_MPTCP. 278 4. DHCPv4 MPTCP Option 280 4.1. Format 282 The DHCPv4 MPTCP option can be used to configure a list of IPv4 283 addresses of an MCP. The format of this option is illustrated in 284 Figure 3. 286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Code | Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | List-Length | List of | 291 +-+-+-+-+-+-+-+-+ MPTCP | 292 / MCP IPv4 Addresses / 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 294 | List-Length | List of | | 295 +-+-+-+-+-+-+-+-+ MPTCP | | 296 / MCP IPv4 Addresses / | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 298 . ... . optional 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 300 | List-Length | List of | | 301 +-+-+-+-+-+-+-+-+ MPTCP | | 302 / MCP IPv4 Addresses / | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 305 Figure 3: DHCPv4 MPTCP option 307 The fields of the option shown in Figure 3 are as follows: 309 o Code: OPTION_V4_MPTCP (TBA, see Section 8.2); 310 o Length: Length of all included data in octets. The minimum length 311 is 5. 312 o List-Length: Length of the "List of MCP IPv4 Addresses" field in 313 octets; MUST be a multiple of 4. 314 o List of MCP IPv4 Addresses: Contains one or more IPv4 addresses of 315 the MCP to be used by the MPTCP client. The format of this field 316 is shown in Figure 4. 317 o OPTION_V4_MPTCP can include multiple lists of MCP IPv4 addresses; 318 each list is treated separately as it corresponds to a given MCP. 320 When several lists of MCP IPv4 addresses are to be included, 321 "List-Length" and "MCP IPv4 Addresses" fields are repeated. 323 0 8 16 24 32 40 48 324 +-----+-----+-----+-----+-----+-----+-- 325 | a1 | a2 | a3 | a4 | a1 | a2 | ... 326 +-----+-----+-----+-----+-----+-----+-- 327 IPv4 Address 1 IPv4 Address 2 ... 329 This format assumes that an IPv4 address is encoded as a1.a2.a3.a4. 331 Figure 4: Format of the List of MCP IPv4 Addresses 333 OPTION_V4_MPTCP is a concatenation-requiring option. As such, the 334 mechanism specified in [RFC3396] MUST be used if OPTION_V4_MPTCP 335 exceeds the maximum DHCPv4 option size of 255 octets. 337 4.2. DHCPv4 Client Behavior 339 To discover one or more MCPs, the DHCPv4 client MUST include 340 OPTION_V4_MPTCP in a Parameter Request List Option [RFC2132]. 342 The DHCPv4 client MUST be prepared to receive multiple lists of MCP 343 IPv4 addresses in the same OPTION_V4_MPTCP; each list is to be 344 treated as a separate MCP instance. 346 The DHCPv4 client MUST silently discard multicast and host loopback 347 addresses [RFC6890] conveyed in OPTION_V4_MPTCP. 349 5. DHCP Server Configuration Guidelines 351 DHCP servers that support the DHCP MCP option can be configured with 352 a list of IP addresses of the MCP(s). If multiple IP addresses are 353 configured, the DHCP server MUST be explicitly configured whether all 354 or some of these addresses refer to: 356 1. the same MCP: the DHCP server returns multiple addresses in the 357 same instance of the DHCP MCP option. 359 2. distinct MCPs : the DHCP server returns multiple lists of MCP IP 360 addresses to the requesting DHCP client (encoded as multiple 361 OPTION_V6_MPTCP or in the same OPTION_V4_MPTCP); each list refers 362 to a distinct MCP. 364 Precisely how DHCP servers are configured to separate lists of IP 365 addresses according to which MCP they refer to is out of scope for 366 this document. However, DHCP servers MUST NOT combine the IP 367 addresses of multiple MCPs and return them to the DHCP client as if 368 they were belonging to a single MCP, and DHCP servers MUST NOT 369 separate the addresses of a single MCP and return them as if they 370 were belonging to distinct MCPs. For example, if an administrator 371 configures the DHCP server by providing a Fully Qualified Domain Name 372 (FQDN) for an MCP, even if that FQDN resolves to multiple addresses, 373 the DHCP server MUST deliver them within a single server address 374 block. 376 DHCPv6 servers that implement this option and that can populate the 377 option by resolving FQDNs will need a mechanism for indicating 378 whether to query A records or only AAAA records. When a query 379 returns A records, the IP addresses in those records are returned in 380 the DHCPv6 response as IPv4-mapped IPv6 addresses. 382 Since this option requires support for IPv4-mapped IPv6 addresses, a 383 DHCPv6 server implementation will not be complete if it does not 384 query A records and represent any that are returned as IPv4-mapped 385 IPv6 addresses in DHCPv6 responses. The mechanism whereby DHCPv6 386 implementations provide this functionality is beyond the scope of 387 this document. 389 For guidelines on providing context-specific configuration 390 information (e.g., returning a regional-based configuration), and 391 information on how a DHCP server might be configured with FQDNs that 392 get resolved on demand, see [RFC7969]. 394 6. Security Considerations 396 The security considerations in [RFC2131] and [RFC3315] are to be 397 considered. 399 MPTCP-related security considerations are discussed in [RFC6824]. 401 Means to protect the MCP against Denial-of-Service (DoS) attacks must 402 be enabled. Such means include the enforcement of ingress filtering 403 policies at the boundaries of the network. In order to prevent 404 exhausting the resources of the MCP by creating an aggressive number 405 of simultaneous subflows for each MPTCP connection, the administrator 406 should limit the number of allowed subflows per host for a given 407 connection. 409 Attacks outside the domain can be prevented if ingress filtering is 410 enforced. Nevertheless, attacks from within the network between a 411 host and an MCP instance are yet another actual threat. Means to 412 ensure that illegitimate nodes cannot connect to a network should be 413 implemented. 415 Traffic theft is also a risk if an illegitimate MCP is inserted in 416 the path. Indeed, inserting an illegitimate MCP in the forwarding 417 path allows to intercept traffic and can therefore provide access to 418 sensitive data issued by or destined to a host. To mitigate this 419 threat, secure means to discover an MCP (for non-transparent modes) 420 should be enabled. 422 7. Privacy Considerations 424 Generic privacy-related considerations are discussed in [RFC7844]. 426 The MCP may have access to privacy-related information (e.g., 427 International Mobile Subscriber Identity (IMSI), link identifier, 428 subscriber credentials, etc.). The MCP must not leak such sensitive 429 information outside an administrative domain. 431 8. IANA Considerations 433 8.1. DHCPv6 Option 435 IANA is requested to assign the following new DHCPv6 Option Code in 436 the registry maintained in http://www.iana.org/assignments/ 437 dhcpv6-parameters: 439 Option Name Value 440 --------------- ----- 441 OPTION_V6_MPTCP TBA 443 8.2. DHCPv4 Option 445 IANA is requested to assign the following new DHCPv4 Option Code in 446 the registry maintained in http://www.iana.org/assignments/bootp- 447 dhcp-parameters/: 449 Option Name Value Data length Meaning 450 --------------- ----- ------------- --------------------------------- 451 OPTION_V4_MPTCP TBA Variable; the Includes one or multiple lists of 452 minimum MCP IP addresses; each list is 453 length is 5. treated as a separate MCP. 455 9. Acknowledgements 457 Many thanks to Olivier Bonaventure for the feedback on this document. 458 Olivier suggested to define the option as a name but that design 459 approach was debated several times within the dhc wg. 461 Thanks to Dan Seibel, Bernie Volz, Niall O'Reilly, Simon Hobson, and 462 Ted Lemon for the feedback on the dhc wg mailing list. 464 10. References 466 10.1. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 474 RFC 2131, DOI 10.17487/RFC2131, March 1997, 475 . 477 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 478 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 479 . 481 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 482 C., and M. Carney, "Dynamic Host Configuration Protocol 483 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 484 2003, . 486 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 487 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 488 DOI 10.17487/RFC3396, November 2002, 489 . 491 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 492 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 493 2006, . 495 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 496 "TCP Extensions for Multipath Operation with Multiple 497 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 498 . 500 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 501 "Special-Purpose IP Address Registries", BCP 153, 502 RFC 6890, DOI 10.17487/RFC6890, April 2013, 503 . 505 10.2. Informative References 507 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 508 RFC 793, DOI 10.17487/RFC0793, September 1981, 509 . 511 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 512 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 513 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 514 . 516 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 517 Profiles for DHCP Clients", RFC 7844, 518 DOI 10.17487/RFC7844, May 2016, 519 . 521 [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP 522 Configuration on the Basis of Network Topology", RFC 7969, 523 DOI 10.17487/RFC7969, October 2016, 524 . 526 Authors' Addresses 528 Mohamed Boucadair 529 Orange 530 Rennes 35000 531 France 533 Email: mohamed.boucadair@orange.com 535 Christian Jacquenet 536 Orange 537 Rennes 538 France 540 Email: christian.jacquenet@orange.com 542 Tirumaleswar Reddy 543 Cisco Systems, Inc. 544 Cessna Business Park, Varthur Hobli 545 Sarjapur Marathalli Outer Ring Road 546 Bangalore, Karnataka 560103 547 India 549 Email: tireddy@cisco.com