From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7857.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc7857.txt (limited to 'doc/rfc/rfc7857.txt') diff --git a/doc/rfc/rfc7857.txt b/doc/rfc/rfc7857.txt new file mode 100644 index 0000000..94b519c --- /dev/null +++ b/doc/rfc/rfc7857.txt @@ -0,0 +1,787 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Penno +Request for Comments: 7857 Cisco +BCP: 127 S. Perreault +Updates: 4787, 5382, 5508 Jive Communications +Category: Best Current Practice M. Boucadair, Ed. +ISSN: 2070-1721 Orange + S. Sivakumar + Cisco + K. Naito + NTT + April 2016 + + + Updates to Network Address Translation (NAT) Behavioral Requirements + +Abstract + + This document clarifies and updates several requirements of RFCs + 4787, 5382, and 5508 based on operational and development experience. + The focus of this document is Network Address Translation from IPv4 + to IPv4 (NAT44). + + This document updates RFCs 4787, 5382, and 5508. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7857. + + + + + + + + + + + + + + +Penno, et al. Best Current Practice [Page 1] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Penno, et al. Best Current Practice [Page 2] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. TCP Session Tracking . . . . . . . . . . . . . . . . . . . . 4 + 2.1. TCP Transitory Connection Idle-Timeout . . . . . . . . . 6 + 2.2. TCP RST . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Port Overlapping Behavior . . . . . . . . . . . . . . . . . . 6 + 4. Address Pooling Paired (APP) . . . . . . . . . . . . . . . . 7 + 5. Endpoint-Independent Mapping (EIM) Protocol Independence . . 8 + 6. Endpoint-Independent Filtering (EIF) Protocol Independence . 8 + 7. Endpoint-Independent Filtering (EIF) Mapping Refresh . . . . 8 + 7.1. Outbound Mapping Refresh and Error Packets . . . . . . . 9 + 8. Port Parity . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 9. Port Randomization . . . . . . . . . . . . . . . . . . . . . 9 + 10. IP Identification (IP ID) . . . . . . . . . . . . . . . . . . 10 + 11. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . . 10 + 12. Hairpinning Support for ICMP Packets . . . . . . . . . . . . 10 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 14.2. Informative References . . . . . . . . . . . . . . . . . 12 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + +1. Introduction + + [RFC4787], [RFC5382], and [RFC5508] contributed to enhance Network + Address Translation (NAT) interoperability and conformance. + Operational experience gained through widespread deployment and + evolution of NAT indicates that some areas of the original documents + need further clarification or updates. This document provides such + clarifications and updates. + +1.1. Scope + + The goal of this document is to clarify and update the set of + requirements listed in [RFC4787], [RFC5382], and [RFC5508]. The + document focuses exclusively on NAT44. + + The scope of this document has been set so that it does not create + new requirements beyond those specified in the documents cited above. + + Requirements related to Carrier-Grade NAT (CGN) are defined in + [RFC6888]. + + + + +Penno, et al. Best Current Practice [Page 3] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + +1.2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + The reader is assumed to be familiar with the terminology defined in + [RFC2663], [RFC4787], [RFC5382], and [RFC5508]. + + In this document, the term "NAT" refers to both "Basic NAT" and + "Network Address/Port Translator (NAPT)" (see Section 3 of + [RFC4787]). As a reminder, Basic NAT and NAPT are two variations of + traditional NAT in that translation in Basic NAT is limited to IP + addresses alone, whereas translation in NAPT is extended to include + IP addresses and transport identifiers (such as a TCP/UDP port or + ICMP query ID); refer to Section 2 of [RFC3022]. + +2. TCP Session Tracking + + [RFC5382] specifies TCP timers associated with various connection + states but does not specify the TCP state machine a NAT44 should + follow as a basis to apply such timers. + + Update: The TCP state machine depicted in Figure 1, adapted from + [RFC6146], SHOULD be implemented by a NAT for TCP session tracking + purposes. + + + + + + + + + + + + + + + + + + + + + + + + + +Penno, et al. Best Current Practice [Page 4] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + + +----------------------------+ + | | + V | + +------+ Client | + |CLOSED|-----SYN------+ | + +------+ | | + ^ | | + |TCP_TRANS T.O. | | + | V | + +-------+ +-------+ | + | TRANS | | INIT | | + +-------+ +-------+ | + | ^ | | + data pkt | | | + | Server/Client RST | | + | TCP_EST T.O. | | + V | Server SYN | + +--------------+ | | + | ESTABLISHED |<---------+ | + +--------------+ | + | | | + Client FIN Server FIN | + | | | + V V | + +---------+ +----------+ | + | C FIN | | S FIN | | + | RCV | | RCV | | + +---------+ +----------+ | + | | | + Server FIN Client FIN TCP_TRANS + | | T.O. + V V | + +----------------------+ | + | C FIN + S FIN RCV |-----------------+ + +----------------------+ + Legend: + * Messages sent or received from the server are + prefixed with "Server". + * Messages sent or received from the client are + prefixed with "Client". + * "C" means "Client-side". + * "S" means "Server-side". + * TCP_EST T.O. refers to the established connection + idle-timeout as defined in [RFC5382]. + * TCP_TRANS T.O. refers to the transitory connection + idle-timeout as defined in [RFC5382]. + + Figure 1: Simplified Version of the TCP State Machine + + + +Penno, et al. Best Current Practice [Page 5] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + +2.1. TCP Transitory Connection Idle-Timeout + + The transitory connection idle-timeout is defined as the minimum time + a TCP connection in the partially open or closing phases must remain + idle before the NAT considers the associated session a candidate for + removal (REQ-5 of [RFC5382]). However, [RFC5382] does not clearly + state whether these can be configured separately. + + Clarification: This document clarifies that a NAT SHOULD provide + different configurable parameters for configuring the open and + closing idle timeouts. + + To accommodate deployments that consider a partially open timeout + of 4 minutes as being excessive from a security standpoint, a NAT + MAY allow the configured timeout to be less than 4 minutes. + However, a minimum default transitory connection idle-timeout of 4 + minutes is RECOMMENDED. + +2.2. TCP RST + + [RFC5382] leaves the handling of TCP RST packets unspecified. + + Update: This document adopts a similar default behavior as in + [RFC6146]. Concretely, when the NAT receives a TCP RST matching + an existing mapping, it MUST translate the packet according to the + NAT mapping entry. Moreover, the NAT SHOULD wait for 4 minutes + before deleting the session and removing any state associated with + it if no packets are received during that 4-minute timeout. + + Notes: + + * Admittedly, the NAT has to verify whether received TCP RST + packets belong to a connection. This verification check is + required to avoid off-path attacks. + + * If the NAT immediately removes the NAT mapping upon receipt of + a TCP RST message, stale connections may be maintained by + endpoints if the first RST message is lost between the NAT and + the recipient. + +3. Port Overlapping Behavior + + REQ-1 from [RFC4787] and REQ-1 from [RFC5382] specify a specific port + overlapping behavior; that is, the external IP address and port can + be reused for connections originating from the same internal source + IP address and port irrespective of the destination. This is known + as Endpoint-Independent Mapping (EIM). + + + + +Penno, et al. Best Current Practice [Page 6] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + + Update: This document clarifies that this port overlapping behavior + may be extended to connections originating from different internal + source IP addresses and ports as long as their destinations are + different. + + The following mechanism MAY be implemented by a NAT: + + If destination addresses and ports are different for outgoing + connections started by local clients, a NAT MAY assign the same + external port as the source ports for the connections. The + port overlapping mechanism manages mappings between external + packets and internal packets by looking at and storing their + 5-tuple (protocol, source address, source port, destination + address, and destination port). + + This enables concurrent use of a single NAT external port for + multiple transport sessions, which allows a NAT to successfully + process packets in a network that has a limited number of IP + addresses (e.g., deployment with a high address space + multiplicative factor (refer to Appendix B of [RFC6269])). + +4. Address Pooling Paired (APP) + + The "IP address pooling" behavior of "Paired" (APP) was recommended + in REQ-2 from [RFC4787], but the behavior when an external IPv4 runs + out of ports was left undefined. + + Clarification: This document clarifies that if APP is enabled, new + sessions from a host that already has a mapping associated with an + external IP that ran out of ports SHOULD be dropped. A + configuration parameter MAY be provided to allow a NAT to start + using ports from another external IP address when the one that + anchored the APP mapping ran out of ports. Tweaking this + configuration parameter is a trade-off between service continuity + and APP strict enforcement. Note, this behavior is sometimes + referred to as "soft-APP". + + As a reminder, the recommendation for the particular case of a CGN + is that an implementation must use the same external IP address + mapping for all sessions associated with the same internal IP + address, be they TCP, UDP, ICMP, something else, or a mix of + different protocols [RFC6888]. + + Update: This behavior SHOULD apply also for TCP. + + + + + + + +Penno, et al. Best Current Practice [Page 7] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + +5. Endpoint-Independent Mapping (EIM) Protocol Independence + + REQ-1 from [RFC4787] and REQ-1 from [RFC5382] do not specify whether + EIM are protocol dependent or protocol independent. For example, if + an outbound TCP SYN creates a mapping, it is left undefined whether + outbound UDP packets can reuse such mapping. + + Update: EIM mappings SHOULD be protocol dependent. A configuration + parameter MAY be provided to allow protocols that multiplex TCP + and UDP over the same source IP address and port number to use a + single mapping. The default value of this configuration parameter + MUST be protocol-dependent EIM. + + This update is consistent with the stateful Network Address and + Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) + [RFC6146] that clearly specifies three binding information bases + (TCP, UDP, and ICMP). + +6. Endpoint-Independent Filtering (EIF) Protocol Independence + + REQ-8 from [RFC4787] and REQ-3 from [RFC5382] do not specify whether + mappings with Endpoint-Independent Filtering (EIF) are protocol + independent or protocol dependent. For example, if an outbound TCP + SYN creates a mapping, it is left undefined whether inbound UDP + packets matching that mapping should be accepted or rejected. + + Update: EIF filtering SHOULD be protocol dependent. A configuration + parameter MAY be provided to make it protocol independent. The + default value of this configuration parameter MUST be protocol- + dependent EIF. + + This behavior is aligned with the update in Section 5. + + Applications that can be transported over a variety of transport + protocols and/or support transport fallback schemes won't + experience connectivity failures if the NAT is configured with + protocol-independent EIM and protocol-independent EIF. + +7. Endpoint-Independent Filtering (EIF) Mapping Refresh + + The NAT mapping Refresh direction may have a "NAT Inbound refresh + behavior" of "True" according to REQ-6 from [RFC4787], but [RFC4787] + does not clarify how this behavior applies to EIF mappings. The + issue in question is whether inbound packets that match an EIF + mapping but do not create a new session due to a security policy + should refresh the mapping timer. + + + + + +Penno, et al. Best Current Practice [Page 8] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + + Clarification: This document clarifies that even when a NAT has an + inbound refresh behavior set to "TRUE", such packets SHOULD NOT + refresh the mapping. Otherwise, a simple attack of a packet every + two minutes can keep the mapping indefinitely. + + Update: This behavior SHOULD apply also for TCP. + +7.1. Outbound Mapping Refresh and Error Packets + + Update: In the case of NAT outbound refresh behavior, ICMP Errors or + TCP RST outbound packets sent as a response to inbound packets + SHOULD NOT refresh the mapping. Other packets that indicate the + host is not interested in receiving packets MAY be configurable to + also not refresh state, such as a Session Traversal Utilities for + NAT (STUN) error response [RFC5389] or IKE INVALID_SYNTAX + [RFC7296]. + +8. Port Parity + + Update: A NAT MAY disable port parity preservation for all dynamic + mappings. Nevertheless, A NAT SHOULD support means to explicitly + request to preserve port parity (e.g., [RFC7753]). + + Note: According to [RFC6887], dynamic mappings are said to be + dynamic in the sense that they are created on demand, either + implicitly or explicitly: + + 1. Implicit dynamic mappings refer to mappings that are created + as a side effect of traffic such as an outgoing TCP SYN or + outgoing UDP packet. Implicit dynamic mappings usually have a + finite lifetime, though this lifetime is generally not known + to the client using them. + + 2. Explicit dynamic mappings refer to mappings that are created + as a result, for example, of explicit Port Control Protocol + (PCP) MAP and PEER requests. Explicit dynamic mappings have a + finite lifetime, and this lifetime is communicated to the + client. + +9. Port Randomization + + Update: A NAT SHOULD follow the recommendations specified in + Section 4 of [RFC6056], especially: + + A NAPT that does not implement port preservation [RFC4787] + [RFC5382] SHOULD obfuscate selection of the ephemeral port of a + packet when it is changed during translation of that packet. + + + + +Penno, et al. Best Current Practice [Page 9] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + + A NAPT that does implement port preservation SHOULD obfuscate + the ephemeral port of a packet only if the port must be changed + as a result of the port being already in use for some other + session. + + A NAPT that performs parity preservation and that must change + the ephemeral port during translation of a packet SHOULD + obfuscate the ephemeral ports. The algorithms described in + this document could be easily adapted such that the parity is + preserved (i.e., force the lowest order bit of the resulting + port number to 0 or 1 according to whether even or odd parity + is desired). + +10. IP Identification (IP ID) + + Update: A NAT SHOULD handle the Identification field of translated + IPv4 packets as specified in Section 5.3.1 of [RFC6864]. + +11. ICMP Query Mappings Timeout + + Section 3.1 of [RFC5508] specifies that ICMP Query mappings are to be + maintained by a NAT. However, the specification doesn't discuss + Query mapping timeout values. Section 3.2 of [RFC5508] only + discusses ICMP Query session timeouts. + + Update: ICMP Query mappings MAY be deleted once the last session + using the mapping is deleted. + +12. Hairpinning Support for ICMP Packets + + REQ-7 from [RFC5508] specifies that a NAT enforcing Basic NAT must + support traversal of hairpinned ICMP Query sessions. + + Clarification: This implicitly means that address mappings from + external address to internal address (similar to Endpoint- + Independent Filters) must be maintained to allow inbound ICMP + Query sessions. If an ICMP Query is received on an external + address, a NAT can then translate to an internal IP. + + REQ-7 from [RFC5508] specifies that all NATs must support the + traversal of hairpinned ICMP Error messages. + + Clarification: This behavior requires a NAT to maintain address + mappings from external IP address to internal IP address in + addition to the ICMP Query mappings described in Section 3.1 of + [RFC5508]. + + + + + +Penno, et al. Best Current Practice [Page 10] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + +13. Security Considerations + + NAT behavioral considerations are discussed in [RFC4787], [RFC5382], + and [RFC5508]. + + Because some of the clarifications and updates (e.g., Section 2) are + inspired from NAT64, the security considerations discussed in + Section 5 of [RFC6146] apply also for this specification. + + The update in Section 3 allows for an optimized NAT resource usage. + In order to avoid service disruption, the NAT must not invoke this + functionality unless the packets are to be sent to distinct + destination addresses. + + Some of the updates (e.g., Sections 7, 9, and 11) allow for increased + security compared to [RFC4787], [RFC5382], and [RFC5508]. + Particularly, + + o the updates in Sections 7 and 11 prevent an illegitimate node to + maintain mappings activated in the NAT while these mappings should + be cleared, and + + o port randomization (Section 9) complicates tracking hosts located + behind a NAT. + + Sections 4 and 12 propose updates that increase the serviceability of + a host located behind a NAT. These updates do not introduce any + additional security concerns to [RFC4787], [RFC5382], and [RFC5508]. + + The updates in Sections 5 and 6 allow for a better NAT transparency + from an application standpoint. Hosts that require a restricted + filtering behavior should enable specific policies (e.g., Access + Control List (ACL)) either locally or by soliciting a dedicated + security device (e.g., firewall). How a host updates its filtering + policies is out of scope of this document. + + The update in Section 8 induces security concerns that are specific + to the protocol used to interact with the NAT. For example, if PCP + is used to explicitly request parity preservation for a given + mapping, the security considerations discussed in [RFC6887] should be + taken into account. + + The update in Section 10 may have undesired effects on the + performance of the NAT in environments in which fragmentation is + massively experienced. Such an issue may be used as an attack vector + against NATs. + + + + + +Penno, et al. Best Current Practice [Page 11] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + +14. References + +14.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address + Translation (NAT) Behavioral Requirements for Unicast + UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January + 2007, . + + [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. + Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, + RFC 5382, DOI 10.17487/RFC5382, October 2008, + . + + [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT + Behavioral Requirements for ICMP", BCP 148, RFC 5508, + DOI 10.17487/RFC5508, April 2009, + . + + [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- + Protocol Port Randomization", BCP 156, RFC 6056, + DOI 10.17487/RFC6056, January 2011, + . + + [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from IPv6 + Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, + April 2011, . + + [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", + RFC 6864, DOI 10.17487/RFC6864, February 2013, + . + +14.2. Informative References + + [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address + Translator (NAT) Terminology and Considerations", + RFC 2663, DOI 10.17487/RFC2663, August 1999, + . + + + + + + + +Penno, et al. Best Current Practice [Page 12] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + + [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, + DOI 10.17487/RFC3022, January 2001, + . + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + DOI 10.17487/RFC5389, October 2008, + . + + [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and + P. Roberts, "Issues with IP Address Sharing", RFC 6269, + DOI 10.17487/RFC6269, June 2011, + . + + [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and + P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, + DOI 10.17487/RFC6887, April 2013, + . + + [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, + A., and H. Ashida, "Common Requirements for Carrier-Grade + NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, + April 2013, . + + [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. + Kivinen, "Internet Key Exchange Protocol Version 2 + (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October + 2014, . + + [RFC7753] Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., + and S. Perreault, "Port Control Protocol (PCP) Extension + for Port-Set Allocation", RFC 7753, DOI 10.17487/RFC7753, + February 2016, . + +Acknowledgements + + Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan, Lars + Eggert, Gorry Fairhurst, Brandon Williams, and David Black for their + review and discussion. + + Many thanks to Ben Laurie for the SecDir review and Dan Romascanu for + the Gen-ART review. + + Dan Wing proposed some text for the configurable errors in + Section 7.1. + + + + + +Penno, et al. Best Current Practice [Page 13] + +RFC 7857 Updates to NAT Behavioral Requirements April 2016 + + +Contributors + + The following individual contributed text to the document: + + Sarat Kamiset + Insieme Networks + United States + +Authors' Addresses + + Reinaldo Penno + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, California 95134 + United States + + Email: repenno@cisco.com + + + Simon Perreault + Jive Communications + Canada + + Email: sperreault@jive.com + + + Mohamed Boucadair (editor) + Orange + Rennes 35000 + France + + Email: mohamed.boucadair@orange.com + + + Senthil Sivakumar + Cisco Systems, Inc. + United States + + Email: ssenthil@cisco.com + + + Kengo Naito + NTT + Tokyo + Japan + + Email: k.naito@nttv6.jp + + + + +Penno, et al. Best Current Practice [Page 14] + -- cgit v1.2.3