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 in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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.”

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 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
2.  Request and Response Packet Format
    2.1.  Request
    2.2.  Response
3.  NAT-PMP Backwards Compatibility
4.  Security Considerations
5.  IANA Considerations
6.  Normative References
§  Author's Address

1.  Introduction

NAT-PMP (Cheshire, S., “NAT Port Mapping Protocol (NAT-PMP),” April 2008.) [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

 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                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.

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

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                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.

 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)                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.  Security Considerations

TBD.

5.  IANA Considerations

TBD.

6. Normative References

Author's Address