Subject: [Softwires] Feedback on draft-wing-softwire-port-control-protocol-01

From: Jason Livingood <[email-masked]>
Date: Sun, 21 Mar 2010 21:56:35 -0400

I thought I¹d send over some feedback re this draft.  Feel free to ignore
some or all of my feedback.  :-)

1  Section 2  Requirements
I like the requirements but find it increasingly useful when documents call
out requirements in a more direct fashion.  Meaning, instead of Section 2
having a general list of 15 items you could call the out as REQ1 to REQ15.
This is of course a matter of personal preference of course. If you use XML
for your I-Ds, you could use this kind of list style:
<list style="format REQ%d:" counter="protocol_requirements_count">

2  Requirement #2: Nothing to change but my expectation is that this can
handle into the 10s of thousands to 100s of thousands of customers.

3  Req 3: protocol semantics is --> protocol semantics are ?

4  Req 4: reword (awkward) --> allows graceful definition of...

5  Re 7: reword: ...can even be notified to a client --> ...can even be
communicated to a client

6  Req 8: ...detect if port control server --> ...detect if the port
control server

7  Req 9: either ³an² existing mapping or ³existing mapping(s)² -- based on
your singular usage of mapping elsewhere, I¹d suggest adding ³an²

8  Seeing Terminology in Section 3, I wonder if it makes sense to place the
terminology before the requirements (which may argue for splitting section 2
into Section 2  Scope, then Section 3  Terminology, then Section 4 
Protocol Requirements).  In the terminology section, it¹d be helpful to have
either direct terms or references relating to NAT64, NAT44, CP Router, and
perhaps even NAT itself (some of this is in place already in your doc).
Would also be nice to define stuff like Port Control Server, Port Requestor,
etc. (or whatever terms you prefer for these elements), which you touch on
in Section 5 (so perhaps a mention that the definitions of specific
functional elements X, Y, and Z can be found in Section XX  as an internal
document reference).  A separate debate is over the use of CP router vs.
home gateway vs. whatever, but that¹s not essential to continued work on the
other points of your document for now.

9  Req 12 and Req 14: ³NATted environments² seems awkward, as it
essentially = Network Address Translationed environments.  I may recommend
the simpler ³NAT environments² or ³environments using NAT² as an alternative

10  ADD new Req: ³Ability to set a Time to Live (TTL) or timer on the port
assignment, after which time the mapping is deleted (destroyed);²  I would
also then add one immediately after this: ³Ability to communicate the TTL
for a given mapping from the Port Control Server to the Port Requestor;²
(you describe Mapping TTL as the Port Mapping Lifetime in 7.1.2 and removal
as Port Mapping Destruction in 7.1.4)

11  Req 14: Recommend references be added for UPnP IGD and NAT-PMP

12  Section 6: Discovery ‹ may want to add ³This list is for example
purposes only and shall not restrict the potential methods for discovery.²
This would make it more clear that new discovery methods may be used over
time, and therefore that the list is non-exclusive.

13  Section 7.1.1, Note-4: Interesting question re challenge/response (to
which I don¹t have a comment at the moment).  At some point I think we
should collectively give some thought to avenues for abuse.

14  Section 7.1.8: I could envision an eventual desire for more specific
result codes relating to errors and other conditions.  Thus, while 3-Deleted
my suffice for now, it may be nice to have that result be, say, 300.  Thus,
eventually you may have 301-Deleted-TTL expired, and
302-Deleted-AtClientRequest, and 303-Deleted-InternalError, etc. This could
be more helpful from an operations standpoint.  For example, I may want to
monitor for 303 responses (in my example) and alarm if I see any or if it
exceeds a certain threshold.  Similarly, the 4  Out of Resources result may
eventually have sub-variants like Memory, -Storage, -Bandwidth, -whatever.
The specific codes desired may only be learned upon implementation of the
protocol, so I suppose I am simply suggesting you build in the ability to
deliver more detailed result codes  later, that are still within the general
categories you have laid out in the I-D.

15  Section 8.1, Part 1: You repeat ³a request² in the 1st sentence

Regards,
Jason

---

From: Paul Selkirk <[email-masked]>
Date: Wed, 24 Mar 2010 18:51:48 +0000 (UTC)

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

---

From: Rémi Després <[email-masked]>
Date: Thu, 25 Mar 2010 16:09:00 -0700

Le 24 mars 2010 à 11:51, Paul Selkirk a écrit :

> Firewall port reservation protocol."  

+1

RD