One document matched: draft-wing-pcp-proposed-packet-format-00.txt




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]


PAFTECH AB 2003-20262026-04-24 09:03:46