A port is an address for some transport protocols. TCP and UDP use port numbers, but they are not the same ports (TCP port 12345, is not UDP port 12345), and other transport protocols may use ports, other, or no addressing.
IP knows nothing about transport protocols or port numbers. The transport PDU is in the payload of IP, and IP only knows what is in its header, not its payload.
NAT is the process of translating a private IP to a public IP
Not exactly. NAT translates one or both of the source and destination IPv4 addresses in a packet header to a different address. It does not matter if either or both of the un- or translated addresses are public or private (in fact, IP has no concept of public or private addressing, that is an artificial distinction by ISP agreement).
Your question seems to assume the NAPT variant of NAT, where not only does the IPv4 addressing get translated, but the TCP or UDP port or the ICMP Query ID also get translated (other transport protocols are not supported, and it can break some application-layer protocols that use TCP or UDP).
How can a port be both be used to identify a private IP, and also to
connect to a specific service? wouldnt that mean this should use at
least two ports?
NAPT maintains translation tables (one each for TCP, UDP, and ICMP) that translate the IPv4 address and transport address combination to a different IPv4 address and transport address combination. There are two addresses each for IPv4 and the transport protocol (A:A<->B:B) in each translation table entry.
RFC 2663, IP Network Address Translator (NAT) Terminology and Considerations explains about Basic NAT and NAPT:
There are two variations to traditional NAT, namely Basic NAT and NAPT
(Network Address Port Translation). These are discussed in the
following sub-sections.
4.1.1.
Basic NAT
With Basic NAT, a block of external addresses are set aside for
translating addresses of hosts in a private domain as they originate
sessions to the external domain. For packets outbound from the private
network, the source IP address and related fields such as IP, TCP, UDP
and ICMP header checksums are translated. For inbound packets, the
destination IP address and the checksums as listed above are
translated.
A Basic NAT router in figure 2 may be configured to translate N-Pri
into a block of external addresses, say Addr-i through Addr-n,
selected from the external network N-Ext.
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.
A NAPT router in figure 2 may be configured to translate sessions
originated from N-Pri into a single external address, say Addr-i.
Very often, the external interface address Addr-Nx of NAPT router is
used as the address to map N-Pri to.
RFC 3022, Traditional IP Network Address Translator (Traditional NAT) also explains:
Abstract
Basic Network Address Translation or Basic NAT is a method by which IP
addresses are mapped from one group to another, transparent to end
users. Network Address Port Translation, or NAPT is a method by which
many network addresses and their TCP/UDP (Transmission Control
Protocol/User Datagram Protocol) ports are translated into a single
network address and its TCP/UDP ports. Together, these two operations,
referred to as traditional NAT, provide a mechanism to connect a realm
with private addresses to an external realm with globally unique
registered addresses.
-also-
Basic NAT and NAPT are two variations of traditional NAT, in that
translation in Basic NAT is limited to IP addresses alone, whereas
translation in NAPT is extended to include IP address and Transport
identifier (such as TCP/UDP port or ICMP query ID).
-and (notice the section I highlighted)-
2.2. Overview of NAPT
Say, an organization has a private IP network and a WAN link to a
service provider. The private network's stub router is assigned a
globally valid address on the WAN link and the remaining nodes in the
organization have IP addresses that have only local significance. In
such a case, nodes on the private network could be allowed
simultaneous access to the external network, using the single
registered IP address with the aid of NAPT. NAPT would allow mapping
of tuples of the type (local IP addresses, local TU port number) to
tuples of the type (registered IP address, assigned TU port number).
This model fits the requirements of most Small Office Home Office
(SOHO) groups to access external network using a single service
provider assigned IP address. This model could be extended to allow
inbound access by statically mapping a local node per each service TU
port of the registered IP address.
In the example of figure 3 below, stub A internally uses class A
address block 10.0.0.0/8. The stub router's WAN interface is assigned
an IP address 138.76.28.4 by the service provider.
\ | /
+-----------------------+
|Service Provider Router|
+-----------------------+
WAN |
|
Stub A .............|....
|
^{s=138.76.28.4,sport=1024, | v{s=138.76.29.7, sport = 23,
^ d=138.76.29.7,dport=23} | v d=138.76.28.4, dport = 1024}
+------------------+
|Stub Router w/NAPT|
+------------------+
|
| LAN
--------------------------------------------
| ^{s=10.0.0.10,sport=3017, | v{s=138.76.29.7, sport=23,
| ^ d=138.76.29.7,dport=23} | v d=10.0.0.10, dport=3017}
| |
+--+ +--+ +--+
|--| |--| |--|
/____\ /____\ /____\
10.0.0.1 10.0.0.2 ..... 10.0.0.10
Figure 3: Network Address Port Translation (NAPT) Operation
When stub A host 10.0.0.10 sends a telnet packet to host 138.76.29.7,
it uses the globally unique address 138.76.29.7 as destination, and
sends the packet to it's primary router. The stub router has a static
route for the subnet 138.76.0.0/16 so the packet is forwarded to the
WAN-link. However, NAPT translates the tuple of source address
10.0.0.10 and source TCP port 3017 in the IP and TCP headers into the globally unique 138.76.28.4 and a uniquely assigned TCP port, say
1024, before the packet is forwarded. Packets on the return path go
through similar address and TCP port translations for the target IP
address and target TCP port. Once again, notice that this requires no
changes to hosts or routers. The translation is completely
transparent.
In this setup, only TCP/UDP sessions are allowed and must originate from the local network. However, there are services such as DNS that
demand inbound access. There may be other services for which an
organization wishes to allow inbound session access. It is possible to
statically configure a well known TU port service [RFC 1700] on the
stub router to be directed to a specific node in the private
network.
In addition to TCP/UDP sessions, ICMP messages, with the exception of
REDIRECT message type may also be monitored by NAPT router. ICMP query
type packets are translated similar to that of TCP/UDP packets, in
that the identifier field in ICMP message header will be uniquely
mapped to a query identifier of the registered IP address. The
identifier field in ICMP query messages is set by Query sender and
returned unchanged in response message from the Query responder. So,
the tuple of (Local IP address, local ICMP query identifier) is mapped
to a tuple of (registered IP address, assigned ICMP query Identifier)
by the NAPT router to uniquely identify ICMP queries of all types from
any of the local hosts. Modifications to ICMP error messages are
discussed in a later section, as that involves modifications to ICMP
payload as well as the IP and ICMP headers.
In NAPT setup, where the registered IP address is the same as the IP
address of the stub router WAN interface, the router has to be sure to
make distinction between TCP, UDP or ICMP query sessions originated
from itself versus those originated from the nodes on local network.
All inbound sessions (including TCP, UDP and ICMP query sessions) are
assumed to be directed to the NAT router as the end node, unless the
target service port is statically mapped to a different node in the
local network.
Sessions other than TCP, UDP and ICMP query type are simply not
permitted from local nodes, serviced by a NAPT router.
As you can see, NAT, and in particular NAPT, is very resource intensive of a NAT router, requiring CPU and RAM well beyond that of simple routing, and it can slow packet forwarding. Many vendors use special hardware to mitigate that, but it comes at extra cost and power usage for the vendor.
NAPT is really a kludge that breaks the IP end-to-end paradigm where every host has a unique address in order to extend the life of IPv4 until IPv6 is ubiquitous. NAPT has limited the protocols that can be used from private addresses across the public Internet, stifling innovation. IPv6 has enough addresses that every host can have a global address, restoring the IP end-to-end paradigm, and allowing transport protocols other than TCP and UDP.
While there is an experimental, not standards track, RFC for IPv6 NAT, it requires a one-to-one Basic NAT, and it explicitly forbids NAPT and transport address translation because that breaks the IP end-to-end paradigm that IPv6 is meant to restore. There are OSes that can be configured to do NAPT with IPv6, but it is pointless and detrimental.
