Subject: [pcp] Protocols: 16-bit port number

From: Flávio Montenegro Filho <[email-masked]>
Date: Tue, 17 Jan 2012 17:58:34 -0300

Hi everyone!

I am implementing a PCP Client and I have a doubt regarding the following part of the PCP I-D: 

9.2 Generanting a MAP Request

   If the Protocol does not use 16-bit port numbers (e.g., RSVP), the
   port number MUST be 0.  This will cause all traffic matching that
   protocol to be mapped.

The document refers RSVP as an example of protocol which does not use 16-bit port number, but I am not sure about other protocols besides RSVP.
Only TCP, UDP, UDP LITE, SCTP and DCCP [http://tools.ietf.org/html/rfc6335#section-6] use 16-bit port numbers? Can anyone help me by pointing other protocols which do not use 16-bit port numbers?

Best Regards

Flávio Augusto Carvalho Montenegro Filho 
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 17 Jan 2012 19:07:30 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Flávio Montenegro Filho
> Sent: Tuesday, January 17, 2012 12:59 PM
> To: [email-masked]
> Subject: [pcp] Protocols: 16-bit port number
> 
> 
> Hi everyone!
> 
> The document refers RSVP as an example of protocol which does not use
> 16-bit port number, but I am not sure about other protocols besides
> RSVP.
> Only TCP, UDP, UDP LITE, SCTP and DCCP
> [http://tools.ietf.org/html/rfc6335#section-6] use 16-bit port numbers?
> Can anyone help me by pointing other protocols which do not use 16-bit
> port numbers?

I looked at
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
and IPsec ESP, IPsec AH, IGMP, and GRE don't use port numbers.  Probably
many
more don't use port numbers.

For any protocol to work, the PCP client and the PCP server need to both
support the specific protocol number.  With that support would come a mutual

understanding of (a) if that specific protocol number uses ports (b) where
the port numbers are encoded in the protocol.  I'm sure you noticed that
PCP only supports 16 bit port numbers (because to our knowledge all of the
protocols registered at
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
that use ports have 16 bit port numbers).  If we find a need, later, for
longer port numbers for some protocol, PCP can be extended with a 
mandatory-to-process Option that always accompanies requests for the
protocol that uses longer port numbers.

-d

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 18 Jan 2012 13:34:29 +0900

Dan Wing wrote:

>> 16-bit port number,

RSVP does use 16-bit port numbers in filter spec, though
the port numbers are of other L4 protocols and not of RSVP.

The port numbers of RSVP is in scope of NAT functions, that
is, must be mapped by a gateway performing port mapping if
the gateway also support RSVP,

More practically, ICMP error packets also need mapping of
port numbers of inner packets.

> more don't use port numbers.

As for IPsec, I wrote in draft-ohta-e2e-nat-00.txt:

   For example, ESP
   packets may be demultiplexed based on the lower 16 bit of SPI. To do
   so, a destination host must be able to control the lower 16 bit of
   SPI.

   For example, AH packets may be demultiplexed as if the lower 16 bit
   of SPI, located at the seventh and eighth bytes of a payload, is a
   destination port number.

> If we find a need, later, for

Last year, I wrote a paper titled:

	TCP and UDP with Port Length Enhancement (TUPLE)
	-- A Scribbled Slate Approach for Internet Addressing
	and Routing --

	ftp://chacha.hpcl.titech.ac.jp/iatuple.pdf
	ftp://chacha.hpcl.titech.ac.jp/iatuple.ppt

to have TCP and UDP analog with 48bit port numbers, 32 bit of
which is intended to be used to extend IPv4 address space.

					Masataka Ohta

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 18 Jan 2012 11:39:03 -0800

> Sent: Tuesday, January 17, 2012 8:34 PM
> To: [email-masked]
> Subject: Re: [pcp] Protocols: 16-bit port number
> 
> Dan Wing wrote:
> 

In my view, a NAT that has an RSVP-ALG function would rewrite
those, as appropriate.  I don't see that PCP can get involved
with the ALG function, nor how PCP could instruct/inform the
NAT about is happening with that.

> port numbers of inner packets.

Agreed.

And PCP already requires that ICMP errors be mapped by a NAT, 
as a  side effect of creating a transport mapping (TCP, UDP,
SCTP, DCCP, etc.),
http://tools.ietf.org/html/draft-ietf-pcp-base-21#section-10
says:

   As a side-effect of creating a mapping, ICMP messages associated with
   the mapping MUST be forwarded (and also translated, if appropriate)
   for the duration of the mapping's lifetime.  This is done to ensure
   that ICMP messages can still be used by hosts, without application
   programmers or PCP client implementations needing to use PCP
   separately to create ICMP mappings for those flows.

ICMP can be allowed/denied using PCP, for firewall purposes (e.g.,
to tell a firewall to allow a host to receive ICMP echo-requests).
Right now, because ICMP does not use ports, PCP can only control
ICMP with all-or-nothing semantics.  If someone wants to describe
a new PCP Option to allow more specific rules (e.g., allow just
ICMP echo-request and deny other ICMP messages; allow just ICMP
TTL exceeded and PTB and deny other ICMP messages), PCP can be
extended in that way.  I don't feel there is much interest in
that at this time, however.

>    of SPI, located at the seventh and eighth bytes of a payload, is a

Are you suggesting PCP can accommodate those ideas in some way?

> which is intended to be used to extend IPv4 address space.

There is also draft-sunjianping-behave-nat-port-expand which
is a similar idea.  PCP could be extended to handle either
of those ideas, should there be sufficient interest.  (I admit
that I only skimmed your TUPLE idea, and I felt TUPLE had
architectural similarities to LISP http://tools.ietf.org/wg/lisp).

-d

> 					Masataka Ohta
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp