idnits 2.17.1 draft-ietf-tsvwg-behave-requirements-update-08.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 (Using the creation date from RFC4787, updated by this document, for RFC5378 checks: 2005-01-13) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (March 2, 2016) is 2974 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG R. Penno 3 Internet-Draft Cisco 4 Updates: 4787, 5382, 5508 (if approved) S. Perreault 5 Intended status: Best Current Practice Jive Communications 6 Expires: September 3, 2016 M. Boucadair, Ed. 7 Orange 8 S. Sivakumar 9 Cisco 10 K. Naito 11 NTT 12 March 2, 2016 14 Network Address Translation (NAT) Behavioral Requirements Updates 15 draft-ietf-tsvwg-behave-requirements-update-08 17 Abstract 19 This document clarifies and updates several requirements of RFC4787, 20 RFC5382, and RFC5508 based on operational and development experience. 21 The focus of this document is NAT44. 23 This document updates RFCs 4787, 5382, and 5508. 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 September 3, 2016. 42 Copyright Notice 44 Copyright (c) 2016 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. TCP Session Tracking . . . . . . . . . . . . . . . . . . . . 3 75 2.1. TCP Transitory Connection Idle-Timeout . . . . . . . . . 5 76 2.2. TCP RST . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Port Overlapping Behavior . . . . . . . . . . . . . . . . . . 5 78 4. Address Pooling Paired (APP) . . . . . . . . . . . . . . . . 6 79 5. Endpoint-Independent Mapping (EIM) Protocol Independence . . 7 80 6. Endpoint-Independent Filtering (EIF) Protocol Independence . 7 81 7. Endpoint-Independent Filtering (EIF) Mapping Refresh . . . . 7 82 7.1. Outbound Mapping Refresh and Error Packets . . . . . . . 8 83 8. Port Parity . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 9. Port Randomization . . . . . . . . . . . . . . . . . . . . . 8 85 10. IP Identification (IP ID) . . . . . . . . . . . . . . . . . . 9 86 11. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . . 9 87 12. Hairpinning Support for ICMP Packets . . . . . . . . . . . . 9 88 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 89 14. Security Considerations . . . . . . . . . . . . . . . . . . . 10 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 15.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 15.2. Informative References . . . . . . . . . . . . . . . . . 11 93 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 94 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 97 1. Introduction 99 [RFC4787], [RFC5382], and [RFC5508] contributed to enhance Network 100 Address Translation (NAT) interoperability and conformance. 101 Operational experience gained through widespread deployment and 102 evolution of NAT indicates that some areas of the original documents 103 need further clarification or updates. This document provides such 104 clarifications and updates. 106 1.1. Scope 108 The goal of this document is to clarify and update the set of 109 requirements listed in [RFC4787], [RFC5382], and [RFC5508]. The 110 document focuses exclusively on NAT44. 112 The scope of this document has been set so that it does not create 113 new requirements beyond those specified in the documents cited above. 115 Carrier-Grade NAT (CGN) related requirements are defined in 116 [RFC6888]. 118 1.2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 The reader is assumed to be familiar with the terminology defined in: 125 [RFC2663],[RFC4787],[RFC5382], and [RFC5508]. 127 In this document, the term "NAT" refers to both "Basic NAT" and 128 "Network Address/Port Translator (NAPT)" (see Section 3 of 129 [RFC4787]). As a reminder, Basic NAT and NAPT are two variations of 130 traditional NAT, in that translation in Basic NAT is limited to IP 131 addresses alone, whereas translation in NAPT is extended to include 132 IP address and Transport identifier (such as TCP/UDP port or ICMP 133 query ID) (refer to Section 2 of [RFC3022]). 135 2. TCP Session Tracking 137 [RFC5382] specifies TCP timers associated with various connection 138 states but does not specify the TCP state machine a NAT44 should 139 follow as a basis to apply such timers. 141 Update: The TCP state machine depicted in Figure 1, adapted from 142 [RFC6146], SHOULD be implemented by a NAT for TCP session tracking 143 purposes. 145 +----------------------------+ 146 | | 147 V | 148 +------+ Client | 149 |CLOSED|-----SYN------+ | 150 +------+ | | 151 ^ | | 152 |TCP_TRANS T.O. | | 153 | V | 154 +-------+ +-------+ | 155 | TRANS | | INIT | | 156 +-------+ +-------+ | 157 | ^ | | 158 data pkt | | | 159 | Server/Client RST | | 160 | TCP_EST T.O. | | 161 V | Server SYN | 162 +--------------+ | | 163 | ESTABLISHED |<---------+ | 164 +--------------+ | 165 | | | 166 Client FIN Server FIN | 167 | | | 168 V V | 169 +---------+ +----------+ | 170 | C FIN | | S FIN | | 171 | RCV | | RCV | | 172 +---------+ +----------+ | 173 | | | 174 Server FIN Client FIN TCP_TRANS 175 | | T.O. 176 V V | 177 +----------------------+ | 178 | C FIN + S FIN RCV |-----------------+ 179 +----------------------+ 180 Legend: 181 * Messages sent or received from the server are 182 prefixed with "Server". 183 * Messages sent or received from the client are 184 prefixed with "Client". 185 * "C" means "Client-side" 186 * "S" means "Server-side". 187 * TCP_EST T.O: refers to the established connection 188 idle timeout as defined in [RFC5382]. 189 * TCP_TRANS T.O: refers to the transitory connection 190 idle timeout as defined in [RFC5382]. 192 Figure 1: Simplified version of the TCP State Machine 194 2.1. TCP Transitory Connection Idle-Timeout 196 The transitory connection idle-timeout is defined as the minimum time 197 a TCP connection in the partially open or closing phases must remain 198 idle before the NAT considers the associated session a candidate for 199 removal (REQ-5 of [RFC5382]). But [RFC5382] does not clearly state 200 whether these can be configured separately. 202 Clarification: This document clarifies that a NAT SHOULD provide 203 different configurable parameters for configuring the open and 204 closing idle timeouts. 206 To accommodate deployments that consider a partially open timeout 207 of 4 minutes as being excessive from a security standpoint, a NAT 208 MAY allow the configured timeout to be less than 4 minutes. 209 However, a minimum default transitory connection idle-timeout of 4 210 minutes is RECOMMENDED. 212 2.2. TCP RST 214 [RFC5382] leaves the handling of TCP RST packets unspecified. 216 Update: This document adopts a similar default behavior as in 217 [RFC6146]. Concretely, when the NAT receives a TCP RST matching 218 an existing mapping, it MUST translate the packet according to the 219 NAT mapping entry. Moreover, the NAT SHOULD wait for 4 minutes 220 before deleting the session and removing any state associated with 221 it if no packets are received during that 4 minutes timeout. 223 Notes: 225 * Admittedly, the NAT has to verify whether received TCP RST 226 packets belong to a connection. This verification check is 227 required to avoid off-path attacks. 229 * If the NAT removes immediately the NAT mapping upon receipt of 230 a TCP RST message, stale connections may be maintained by 231 endpoints if the first RST message is lost between the NAT and 232 the recipient. 234 3. Port Overlapping Behavior 236 REQ-1 from [RFC4787] and REQ-1 from [RFC5382] specify a specific port 237 overlapping behavior; that is the external IP address and port can be 238 reused for connections originating from the same internal source IP 239 address and port irrespective of the destination. This is known as 240 endpoint-independent mapping (EIM). 242 Update: This document clarifies that this port overlapping behavior 243 may be extended to connections originating from different internal 244 source IP addresses and ports as long as their destinations are 245 different. 247 The following mechanism MAY be implemented by a NAT: 249 If destination addresses and ports are different for outgoing 250 connections started by local clients, a NAT MAY assign the same 251 external port as the source ports for the connections. The 252 port overlapping mechanism manages mappings between external 253 packets and internal packets by looking at and storing their 254 5-tuple (protocol, source address, source port, destination 255 address, destination port). 257 This enables concurrent use of a single NAT external port for 258 multiple transport sessions, which allows a NAT to successfully 259 process packets in an IP address resource limited network (e.g., 260 deployment with high address space multiplicative factor (refer to 261 Appendix B. of [RFC6269])). 263 4. Address Pooling Paired (APP) 265 The "IP address pooling" behavior of "Paired" (APP) was recommended 266 in REQ-2 from [RFC4787], but the behavior when an external IPv4 runs 267 out of ports was left undefined. 269 Clarification: This document clarifies that if APP is enabled, new 270 sessions from a host that already has a mapping associated with an 271 external IP that ran out of ports SHOULD be dropped. A 272 configuration parameter MAY be provided to allow a NAT to starting 273 using ports from another external IP address when the one that 274 anchored the APP mapping ran out of ports. Tweaking this 275 configuration parameter is a trade-off between service continuity 276 and APP strict enforcement. Note, this behavior is sometimes 277 referred as 'soft-APP'. 279 As a reminder, the recommendation for the particular case of a CGN 280 is that an implementation must use the same external IP address 281 mapping for all sessions associated with the same internal IP 282 address, be they TCP, UDP, ICMP, something else, or a mix of 283 different protocols [RFC6888]. 285 Update: This behavior SHOULD apply also for TCP. 287 5. Endpoint-Independent Mapping (EIM) Protocol Independence 289 REQ-1 from [RFC4787] and REQ-1 from [RFC5382] do not specify whether 290 EIM are protocol-dependent or protocol-independent. For example, if 291 an outbound TCP SYN creates a mapping, it is left undefined whether 292 outbound UDP packets can reuse such mapping. 294 Update: EIM mappings SHOULD be protocol-dependent. A configuration 295 parameter MAY be provided to allow protocols that multiplex TCP 296 and UDP over the same source IP address and port number to use a 297 single mapping. The default value of this configuration parameter 298 MUST be protocol-dependent EIM. 300 This update is consistent with the stateful NAT64 [RFC6146] that 301 clearly specifies three binding information bases (TCP, UDP, 302 ICMP). 304 6. Endpoint-Independent Filtering (EIF) Protocol Independence 306 REQ-8 from [RFC4787] and REQ-3 from [RFC5382] do not specify whether 307 mappings with endpoint-independent filtering (EIF) are protocol- 308 independent or protocol-dependent. For example, if an outbound TCP 309 SYN creates a mapping, it is left undefined whether inbound UDP 310 packets matching that mapping should be accepted or rejected. 312 Update: EIF filtering SHOULD be protocol-dependent. A configuration 313 parameter MAY be provided to make it protocol-independent. The 314 default value of this configuration parameter MUST be protocol- 315 dependent EIF. 317 This behavior is aligned with the update in Section 5. 319 Applications that can be transported over a variety of transport 320 protocols and/or support transport fall back schemes won't 321 experience connectivity failures if the NAT is configured with 322 protocol-independent EIM and protocol-independent EIF. 324 7. Endpoint-Independent Filtering (EIF) Mapping Refresh 326 The NAT mapping Refresh direction may have a "NAT Inbound refresh 327 behavior" of "True" according to REQ-6 from [RFC4787], but [RFC4787] 328 does not clarify how this behavior applies to EIF mappings. The 329 issue in question is whether inbound packets that match an EIF 330 mapping but do not create a new session due to a security policy 331 should refresh the mapping timer. 333 Clarification: This document clarifies that even when a NAT has an 334 inbound refresh behavior set to 'TRUE', such packets SHOULD NOT 335 refresh the mapping. Otherwise a simple attack of a packet every 336 2 minutes can keep the mapping indefinitely. 338 Update: This behavior SHOULD apply also for TCP. 340 7.1. Outbound Mapping Refresh and Error Packets 342 Update: In the case of NAT outbound refresh behavior, ICMP Errors or 343 TCP RST outbound packets, sent as response to inbound packets, 344 SHOULD NOT refresh the mapping. Other packets which indicate the 345 host is not interested in receiving packets MAY be configurable to 346 also not refresh state, such as STUN error response [RFC5389] or 347 IKE INVALID_SYNTAX [RFC7296]. 349 8. Port Parity 351 Update: A NAT MAY disable port parity preservation for all dynamic 352 mappings. Nevertheless, A NAT SHOULD support means to explicitly 353 request to preserve port parity (e.g., [RFC7753]). 355 Note: According to [RFC6887], dynamic mappings are said to be 356 dynamic in the sense that they are created on demand, either 357 implicitly or explicitly: 359 1. Implicit dynamic mappings refer to mappings that are created 360 as a side effect of traffic such as an outgoing TCP SYN or 361 outgoing UDP packet. Implicit dynamic mappings usually have a 362 finite lifetime, though this lifetime is generally not known 363 to the client using them. 365 2. Explicit dynamic mappings refer to mappings that are created 366 as a result, for example, of explicit Port Control Protocol 367 (PCP) MAP and PEER requests. Explicit dynamic mappings have a 368 finite lifetime, and this lifetime is communicated to the 369 client. 371 9. Port Randomization 373 Update: A NAT SHOULD follow the recommendations specified in 374 Section 4 of [RFC6056], especially: 376 "A NAPT that does not implement port preservation [RFC4787] 377 [RFC5382] SHOULD obfuscate selection of the ephemeral port of a 378 packet when it is changed during translation of that packet. A 379 NAPT that does implement port preservation SHOULD obfuscate the 380 ephemeral port of a packet only if the port must be changed as 381 a result of the port being already in use for some other 382 session. A NAPT that performs parity preservation and that 383 must change the ephemeral port during translation of a packet 384 SHOULD obfuscate the ephemeral ports. The algorithms described 385 in this document could be easily adapted such that the parity 386 is preserved (i.e., force the lowest order bit of the resulting 387 port number to 0 or 1 according to whether even or odd parity 388 is desired)." 390 10. IP Identification (IP ID) 392 Update: A NAT SHOULD handle the Identification field of translated 393 IPv4 packets as specified in Section 5.3.1 of [RFC6864]. 395 11. ICMP Query Mappings Timeout 397 Section 3.1 of [RFC5508] specifies that ICMP Query Mappings are to be 398 maintained by a NAT. However, the specification doesn't discuss 399 Query Mapping timeout values. Section 3.2 of [RFC5508] only 400 discusses ICMP Query Session Timeouts. 402 Update: ICMP Query Mappings MAY be deleted once the last session 403 using the mapping is deleted. 405 12. Hairpinning Support for ICMP Packets 407 REQ-7 from [RFC5508] specifies that a NAT enforcing 'Basic NAT' must 408 support traversal of hairpinned ICMP Query sessions. 410 Clarification: This implicitly means that address mappings from 411 external address to internal address (similar to Endpoint 412 Independent Filters) must be maintained to allow inbound ICMP 413 Query sessions. If an ICMP Query is received on an external 414 address, a NAT can then translate to an internal IP. 416 REQ-7 from [RFC5508] specifies that all NATs must support the 417 traversal of hairpinned ICMP Error messages. 419 Clarification: This behavior requires a NAT to maintain address 420 mappings from external IP address to internal IP address in 421 addition to the ICMP Query Mappings described in Section 3.1 of 422 [RFC5508]. 424 13. IANA Considerations 426 This document does not require any IANA action. 428 14. Security Considerations 430 NAT behavioral considerations are discussed in [RFC4787], [RFC5382], 431 and [RFC5508]. 433 Because some of the clarifications and updates (e.g., Section 2) are 434 inspired from NAT64, the security considerations discussed in 435 Section 5 of [RFC6146] apply also for this specification. 437 The update in Section 3 allows for an optimized NAT resource usage. 438 In order to avoid service disruption, the NAT must not invoke this 439 functionality unless the packets are to be sent to distinct 440 destination addresses. 442 Some of the updates (e.g., Section 7, Section 9, and Section 11) 443 allow for an increased security compared to [RFC4787], [RFC5382], and 444 [RFC5508]. Particularly: 446 o The updates in Section 7 and Section 11 prevent an illegitimate 447 node to maintain mappings activated in the NAT while these 448 mappings should be cleared. 450 o Port randomization (Section 9) complicates tracking hosts located 451 behind a NAT. 453 Section 4 and Section 12 propose updates that increase the 454 serviceability of a host located behind a NAT. These updates do not 455 introduce any additional security concerns to [RFC4787], [RFC5382], 456 and [RFC5508]. 458 The updates in Section 5 and Section 6 allow for a better NAT 459 transparency from an application standpoint. Hosts that require a 460 restricted filtering behavior should enable specific policies (e.g., 461 access control list (ACL)) either locally or by soliciting a 462 dedicated security device (e.g., firewall). How a host updates its 463 filtering policies is out of scope of this document. 465 The update in Section 8 induces security concerns that are specific 466 to the protocol used to interact with the NAT. For example, if PCP 467 is used to explicitly request parity preservation for a given 468 mapping, the security considerations discussed in [RFC6887] should be 469 taken into account. 471 The update in Section 10 may have undesired effects on the 472 performance of the NAT in environments in which fragmentation is 473 massively experienced. Such issue may be used as an attack vector 474 against NATs. 476 15. References 478 15.1. Normative References 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, 482 DOI 10.17487/RFC2119, March 1997, 483 . 485 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 486 Translation (NAT) Behavioral Requirements for Unicast 487 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 488 2007, . 490 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 491 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 492 RFC 5382, DOI 10.17487/RFC5382, October 2008, 493 . 495 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 496 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 497 DOI 10.17487/RFC5508, April 2009, 498 . 500 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 501 Protocol Port Randomization", BCP 156, RFC 6056, 502 DOI 10.17487/RFC6056, January 2011, 503 . 505 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 506 NAT64: Network Address and Protocol Translation from IPv6 507 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 508 April 2011, . 510 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 511 RFC 6864, DOI 10.17487/RFC6864, February 2013, 512 . 514 15.2. Informative References 516 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 517 Translator (NAT) Terminology and Considerations", 518 RFC 2663, DOI 10.17487/RFC2663, August 1999, 519 . 521 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 522 Address Translator (Traditional NAT)", RFC 3022, 523 DOI 10.17487/RFC3022, January 2001, 524 . 526 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 527 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 528 DOI 10.17487/RFC5389, October 2008, 529 . 531 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 532 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 533 DOI 10.17487/RFC6269, June 2011, 534 . 536 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 537 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 538 DOI 10.17487/RFC6887, April 2013, 539 . 541 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 542 A., and H. Ashida, "Common Requirements for Carrier-Grade 543 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 544 April 2013, . 546 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 547 Kivinen, "Internet Key Exchange Protocol Version 2 548 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 549 2014, . 551 [RFC7753] Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., 552 and S. Perreault, "Port Control Protocol (PCP) Extension 553 for Port-Set Allocation", RFC 7753, DOI 10.17487/RFC7753, 554 February 2016, . 556 Acknowledgements 558 Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan, Lars 559 Eggert, Gorry Fairhurst, Brandon Williams, and David Black for their 560 review and discussion. 562 Many thanks to Ben Laurie for the secdir review, and Dan Romascanu 563 for the Gen-ART review. 565 Dan Wing proposed some text for the configurable errors in 566 Section 7.1. 568 Contributors 570 The following individual contributed text to the document: 572 Sarat Kamiset, Insieme Networks, United States 574 Authors' Addresses 576 Reinaldo Penno 577 Cisco Systems, Inc. 578 170 West Tasman Drive 579 San Jose, California 95134 580 USA 582 Email: repenno@cisco.com 584 Simon Perreault 585 Jive Communications 586 Canada 588 Email: sperreault@jive.com 590 Mohamed Boucadair (editor) 591 Orange 592 Rennes 35000 593 France 595 Email: mohamed.boucadair@orange.com 597 Senthil Sivakumar 598 Cisco Systems, Inc. 599 United States 601 Email: ssenthil@cisco.com 603 Kengo Naito 604 NTT 605 Tokyo 606 Japan 608 Email: k.naito@nttv6.jp