This is a reasonable protocol as far as it goes. However, I find it
odd that the draft attempts to articially reduce the scope to a
translating proxy for DS-lite and NAT64 only.
There is nothing inherent in the base protocol that supports these
restrictions. It is, to all appearances, "a general purpose NAT or
Firewall port reservation protocol." In fact, given that the packet
formats and most of the descriptive text are lifted wholesale from
NAT-PMP, maybe we should call it NAT-PMPv2, with added support for
proxying and address family translation.
Specifically, the draft should be restructured to spell out the base
client-server protocol, then address all the special cases: directly
connected NAT44, NAT64, PCP/PCP proxy, UPnP/PCP proxy, NAT-PMP/PCP
proxy, DS-lite, NAT444, etc.
(Of course, if we accept that it's a general purpose NAT traversal
protocol, then it would appear to be squarely within the charter for
behave, and only marginally for softwire.)
I support Jason's structural suggestions, and have the following
comments to offer.
7.1.3 (Returning a Mapping) retains the following language from NAT-PMP:
The source address of the packet MUST be used for the internal
address in the mapping. This protocol is not intended to facilitate
one device behind a NAT creating mappings for other devices. If
there are legacy devices that require inbound mappings, permanent
mappings can be created manually by the administrator, just as they
are today.
Not only is this nonsense in a proxying scenario, but it is directly
at odds with requirement 13 (another application on the same host *or
on a different host* can open the port.) Whatever the intent of this
passage, it needs to be rewritten or removed.
7.1.3 also carries over this text, which I would like to see removed,
but which I feel less strongly about:
While a NAT gateway MUST NOT automatically create mappings for TCP
when the client requests UDP, and vice versa, the NAT gateway MUST
reserve the companion port so the same client can choose to map it in
the future. For example, if a client requests to map TCP port 80, as
long as the client maintains the lease for that TCP port mapping,
another client with a different IP address MUST NOT be able to
successfully acquire the mapping for UDP port 80.
7.1.5 (List Port Mappings) is a place-holder. In addition to the
request and reply message formats, I'd like to see some justification
for why this operation is needed (especially in relation to
requirement 1: lightweight protocol).
7.2 (Interactions with Outgoing Sessions) says:
There are a few important considerations when port forwarding is
combined with a NAT that uses address pools. First and foremost, if
there is a port forwarding mapping between certain external and
internal addresses, all sessions originated by the host associated
with the internal address should use the same external address
present in the port forwarding mapping.
(Pedantically, that's not "a few" considerations, that's one.)
Address affinity is good for general operational stability, but the
protocol supports non-affinitive mappings, by reporting the external
address in all mapping responses.
8.3 (NAT or PCP Server reboot) says:
With PCP, the NAT operated by the service provider and the PCP server
are both expected to retain PCP-initiated port mapping information in
permanent storage, so a reboot will cause no loss of port mapping
information.
This is a large and deliberate change from UPnP/NAT-PMP, and implies
something analogous to a DHCP lease database. (However, my HGW DHCP
server doesn't maintain its lease database across reboots either.)
Section 9 (PCP and Dual Stack-Lite) specifically considers the cases
of both tunneled requests and directly-proxied requests.
Nevertheless, the IPv6 address used by the PCP
Proxy MUST be the same as the one used to mount the IPv6 interface of
the B4 element.
I think I understand what this is trying to say (the IPv6 source
address of the proxied request should be that of the proxy host), but
I'm not sure I understand why it needs to be said.
The DS-lite scenario needs to be spelled out in much more detail,
especially since it's the ostensible reason that PCP is in softwire.
DS-lite requires a proxy on the B4. Realistically, it should be a
translating proxy (client-initiated UPnP and NAT-PMP to PCP). On the
AFTR, the NAT mapping table is extended to include the IPv6 source
address of B4, as well as the client's source IPv4 address, protocol,
and port. This requires that the PCP proxy must be on the same host
as the B4; this requirement should be made explicit.
For NAT444, the interior NAT translates (NATs) the request packet, so
it appears to be coming directly from a client. The interior NAT
maintains its mapping, and the exterior NAT maintains its mapping.
The proxy (interior NAT) needs to report the mapped exterior port
number without change, but the interior NAT doesn't have to use the
same port mapping as the exterior NAT.
Regardless of the proxy type (DS-lite or NAT444), the reply message
does not include the internal address of the original requestor. So
the proxy MUST maintain state, to know where to direct the reply
message (probably in the form of a pair of open sockets (to the
client, and to the upstream server)). If we add the internal address
to the reply message, then the proxy can be stateless.
Of course, the retransmit timer defined in 7.1.1 requires state to be
maintained, but it could be argued that it's the responsibility of the
originating client to retransmit, and the proxy should statelessly
relay the retransmision. This means that the retransmission behavior
is that of the originating protocol (UPnP or NAT-PMP, if the proxy is
translating), rather than that of PCP. In addition to adding the
internal address to the reply message, I would also change 7.1.1 to
say that retransmission only applies to native PCP (client-initiated
PCP), not to proxy-initiated PCP.
Hmm, I think I may have argued myself around to the position that PCP
should be a proxy-specific protocol. At any rate, there should be
more discussion of client-initiated PCP vs proxy-initiated PCP.
paul
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
