PCP Working Group D. Wing Internet-Draft Cisco Intended status: Informational October 6, 2010 Expires: April 9, 2011 Proposed PCP Packet Format draft-wing-pcp-proposed-packet-format-00 Abstract A proposed packet format for PCP. This document is for discussion purposes. It is not intended to be published as an RFC. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 9, 2011. Copyright Notice Copyright (c) 2010 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 Wing Expires April 9, 2011 [Page 1] Internet-Draft Proposed PCP Packet Format October 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Request and Response Packet Format . . . . . . . . . . . . . . 3 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. NAT-PMP Backwards Compatibility . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Wing Expires April 9, 2011 [Page 2] Internet-Draft Proposed PCP Packet Format October 2010 1. Introduction NAT-PMP [I-D.cheshire-nat-pmp] is a lightweight, UDP-based request/ response protocol that forms a good basis to obtain mappings from a NAT. This document proposes a packet format, based on NAT-PMP, which provides the necessary extensions and support for PCP. This document is for discussion purposes. It is not intended to be published as an RFC. 2. Request and Response Packet Format The request and response packet formats take the same space and layout. It is intended to be backwards compatible with NAT-PMP, so that if a PCP message is sent to a NAT-PMP server it will be rejected with an error code we can parse. The PCP request uses Version=1, which if processed by a NAT-PMP server will cause a version conflict (the NAT-PMP server will see this as NAT-PMP version 16) and an error returned in the same place we're looking for it (last couple of bits of the 4th byte). 2.1. Request Wing Expires April 9, 2011 [Page 3] Internet-Draft Proposed PCP Packet Format October 2010 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver=1 |reserve| OpCode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Internal IP address (32 or 128) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Requested external IP address (32 or 128) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | internal port | requested external port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : (optional) Informational Elements : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Request Packet Format The Informational Elements (IE) allow extending PCP, without defining a new PCP version and without consuming additional opcodes. They can be used in requests and responses, and are defined in documents specific to each IE. An IANA registry will be created for IEs. IEs are useful in a request when additional information is being specified in the request. Examples that have been discussed, which might be standardized in the future, include mapping DSCP bits, indicating which interface is requested for a mapping on a multi- interface NAT (e.g., internal corporate network address versus an Internet-facing address). IEs will use a Type-Length-Value format. IEs that aren't understood by the server are ignored. Wing Expires April 9, 2011 [Page 4] Internet-Draft Proposed PCP Packet Format October 2010 the Opcode has the following format: +-+-+-+-+-+-+-+-+ |P|0|0|I|E|proto| +-+-+-+-+-+-+-+-+ P=Request=0, Response=1 two zero bits I, Internal address: 0=IPv4, 1=IPv6 E, External address: 0=IPv4, 1=IPv6 proto: 1=UDP, 2=TCP, 0=all (used only for delete) which yields the following values: 1 = NAT44 or IPv4 firewall, UDP 2 = NAT44 or IPv4 firewall, TCP 9 = NAT46, UDP 10 = NAT46, TCP 17 = NAT64, UDP 18 = NAT64, TCP 25 = IPv6 firewall, UDP 26 = IPv6 firewall, TCP Figure 2: Opcode format Wing Expires April 9, 2011 [Page 5] Internet-Draft Proposed PCP Packet Format October 2010 2.2. Response 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver=1 |reserve| Opcode+128 | Reserved | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Internal IP address (32 or 128) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Assigned external IP address (32 or 128) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | internal port | assigned external port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : (optional) Informational Elements : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Response Packet Format 3. NAT-PMP Backwards Compatibility Because NAT-PMP and PCP share the same port, it is important that a NAT-PMP client receive a NAT-PMP error message. This is done by examining the version number of the incoming PCP message; if it is zero, the message is from a NAT-PMP client. A valid NAT-PMP response (rather than a PCP response) is necessary, shown below. A server which supports both NAT-PMP and PCP would be able to process both NAT-PMP and PCP requests normally, and (if necessary) proxy between the protocols. Wing Expires April 9, 2011 [Page 6] Internet-Draft Proposed PCP Packet Format October 2010 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | OP = 128 + x | Result Code=1 (unsupp. vers.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 0 (96 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: NAT-PMP response 4. Security Considerations TBD. 5. IANA Considerations TBD. 6. Normative References [I-D.cheshire-nat-pmp] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", draft-cheshire-nat-pmp-03 (work in progress), April 2008. Author's Address Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 USA Email: dwing@cisco.com Wing Expires April 9, 2011 [Page 7]