Yes, Cisco's documentation lumps what it's doing into the terminology of port numbers, but let's look at RFC2663, beginning with its preface:
Preface
The motivation behind this document is to provide clarity to the
terms used in conjunction with Network Address Translators. The term
"Network Address Translator" means different things in different
contexts. The intent of this document is to define the various
flavors of NAT and standardize the meaning of terms used.
Hmm, interesting purpose, to define clarity to terminology.
They do have a section defining TCP/UDP ports:
2.4. TU ports, Server ports, Client ports
For the reminder of this document, we will refer TCP/UDP ports
associated with an IP address simply as "TU ports".
For most TCP/IP hosts, TU port range 0-1023 is used by servers
listening for incoming connections. Clients trying to initiate a
connection typically select a source TU port in the range of 1024-
65535. However, this convention is not universal and not always
followed. Some client stations initiate connections using a source TU
port number in the range of 0-1023, and there are servers listening
on TU port numbers in the range of 1024-65535.
A list of assigned TU port services may be found in RFC 1700 [Ref 2].
In their section on NAPT (or what we generally call PAT) has:
4.1.2. Network Address Port Translation (NAPT)
NAPT extends the notion of translation one step further by also
translating transport identifier (e.g., TCP and UDP port numbers,
ICMP query identifiers). This allows the transport identifiers of a
number of private hosts to be multiplexed into the transport
identifiers of a single external address. NAPT allows a set of hosts
to share a single external address. Note that NAPT can be combined
with Basic NAT so that a pool of external addresses are used in
conjunction with port translation.
For packets outbound from the private network, NAPT would translate
the source IP address, source transport identifier and related fields
such as IP, TCP, UDP and ICMP header checksums. Transport identifier
can be one of TCP/UDP port or ICMP query ID. For inbound packets, the
destination IP address, destination transport identifier and the IP
and transport header checksums are translated.
The RFC is using the term "transport identifier" because it's not just a TCP/UDP "port number". (Actually, of course, "port" has a very wide generic meaning too, and to be fair, one might term the "port number" shown in Cisco's NAT/PAT table as a "port number", but then it might be easily confused with a TCP/UDP "port number". This, I suspect, is why the RFC uses two different terms, i.e. to make clear they are NOT one and the same.)
In my posts I've been using the term "pseudo port number" in a NAT table because a) it looks like a TCP/UDP port number, but b) it can be more than just a TCP/UDP port number, as it supports "PAT" for traffic without TCP/UDP port numbers. The RFC's "transport identifier", I believe, is trying to convey the same. I.e. when doing IP address overload, "more" is needed to keep flows distinguished. (BTW, there, I believe @MHM Cisco World are in 100% agreement.)
However, where MHM and I appear to disagree, although a NAT table has, what appears as TCP/UDP port numbers, there is a deeper meaning attached to those NAT table "port numbers". Once you understand that, it makes it easy to understand how traffic like ICMP can transit NAT when, ICMP doesn't have port numbers.
Hopefully to make clear what's happing, let's use the example of two hosts contacting the same (web) server, but just happen to be using the same source port.
e.g.
192.168.1.1:4000 => 1.1.1.1:80
192.168.1.2:4000 => 1.1.1.1:80
using a single PAT overloaded IP of 2.2.2.2
what could could be sent is:
2.2.2.2:8000 => 1.1.1.1:80
2.2.2.2:8001 => 1.1.1.1:80
With the "changed" TCP source ports, the web server "sees" two different flows, both from the same address.
Return traffic can be identified and re-translated to original source IPs and port:
I.e.:
1.1.1.1:80 => 2.2.2.2:8000 => 192.168.1.1:4000
1.1.1.1:80 => 2.2.2.2:8001 => 192.168.2.1:4000
The forgoing a great example of NAT/PAT.
But if we have IGMP, like ping, we have:
192.168.1.1 => 1.1.1.1
192.168.1.2 => 1.1.1.1
We have no TCP/UDP port numbers!!!
Yet, if IGMP has something we can "translate" like the RFC's mention of query identifiers, we can do something like:
192.168.1.1(qID 123) => 2.2.2.2:0 => 2.2.2.2(qID 456)
192.168.1.2(qID 123) => 2.2.2.2:1 => 2.2.2.2(qID 789)
The Cisco NAT/PAT table shows "port numbers", but they are not TCP/UDP port numbers, they are, as the RFC describes, transport identifiers, which allows the two way translation, for the outgoing pings and the return ping replies.
As I've noted a couple of times NAT supporting overloading IPs, can get complicated. ICMP, has a RFC describing additional NAT issues, see RFC5508.
BTW, MHM, I hadn't meant to imply that you don't know what you're talking about, but as excellent as Cisco documentation/information often is, there can be deeper concepts being concealed by it, which can, sometimes, lead to confusion. In this case, again, Cisco's presentation of PAT and port numbers, which works great for TCP/UDP traffic, conceals issues that port number translation alone cannot deal with, like ICMP traffic.
Of course, for practical day-to-day network engineering, deep understanding is often not needed, yet when trouble shooting, a deeper understanding can sometimes be very valuable.
