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 <[email protected]>
member of technical staff, core os networking



_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66

Reply via email to