Re: [nat66] Comments on draft-mrw-nat66-12

[james woodyatt <[e-mail]>]

On Mar 15, 2011, at 4:37 PM, Fred Baker wrote:
> 
> The PCP conversation is with the firewall functionality, which is COMPLETELY AND 100% SEPARATE FROM THE NPTv6 TRANSLATOR FUNCTIONALITY.

Not true entirely true.

Using NPTv6 to facilitate site multi-homing as described in section 2.4 means that hosts may have multiple external addresses and PCP servers with which to communicate their port control needs to IPv6 firewalls (c.f. REC-48 in RFC 6092) for ports bound to their single locally prefixed interface identifiers.

PCP assumes deployment only in single-homed sites, and hosts deployed behind NPTv6 translators have no systematic way to determine that they *aren't* in a single-homed site.  Indeed, that's the point of NPTv6: to present an approximation of a single-homed network when in fact the network is multi-homed with provider-aggregated addresses.  Support for PCP will entail a proxy server that handles port control requests from internal addresses and proxies them to the PCP servers for each of the external firewalls.

Moreover, there is an open problem, which the PCP working group will eventually discover in the fullness of time, dealing with external address discovery.  Hosts deployed behind NPTv6 that expect to use PCP to obtain the external addresses mapped to their internal addresses will need to cope with the fact that multiple addresses may be in the list.  Indeed they may get IPv4 addresses too, from NAT64 boxen.  When NPTv6 is used for site multi-homing, then each of the external addresses will need to be returned by the PCP proxy server.  Possibly, each with their own lifetimes.  Not sure what the PCP people will do when they come fact to face with this problem.

Look, you don't have to design a PCP proxy server in this draft.  You just need to point out that PCP will need one.  Either that or you need to point out that site multi-homing with NPTv6 isn't compatible with PCP.  Pick one, but please don't just ignore the issue.


--
james woodyatt <[e-mail]>
member of technical staff, core os networking