Re: IPv6-PMP?

[james woodyatt <jhw@apple.com>]

On Apr 10, 2007, at 18:43, Fred Baker wrote:
> 	ip access-list permit ftp any host ftp.example.com
> 	ip access-list permit ftp-data any host ftp.example.com

Oh, the AirPort Extreme has manually configured IPv4/NAT port  
forwarding.  That's not what I'm talking about.

It's possible for an expert user who 1) knows where to find the  
AirPort Utility, 2) knows how to invoke its advanced configuration  
interface, 3) knows how to find the port-mapping pane and can  
understand how to write a firewall rule, and 4) knows the  
administrative password for the AirPort base station, to set a  
forwarding rule that will do this.  I'm pretty sure we'll end up  
doing something like this in the future for IPv6 (when we can agree  
on a suitable human interface for it in the administrative utility),  
but that's a completely orthogonal problem.

The problem I'm highlighting here is that manually configuring  
firewall rules is way, way beyond the skills of the vast majority of  
our customers.  To remedy that with IPv4/NAT, we integrated NAT-PMP  
into the operating system so that when you start the AFP server (for  
example; it works just as well for SMTP, HTTP, IMAP, foo, bar and  
baz) on your computer (in Mac OS X 10.4, you also have to have the  
Bonjour preference pane installed and configured properly, though  
this may not be required in future operating systems), you  
automatically get the IPv4/NAT port-mapping rule installed in your  
router for you.  No complicated configuration necessary.  It just  
works automatically, and there it is: a mostly reasonable facsimile  
of end-to-end goodness restored to the Internet.

No such facility is available for IPv6, and that strikes me as very  
weird.  For a long time, I had assumed that the reason it wasn't  
there was that we were all expecting that residential IPv6 gateways  
wouldn't need to break the end-to-end transparency of the network by  
blocking flows that didn't match application state, and therefore we  
wouldn't be seeing stateful packet filters at default gateways.   
Alas, I now realize that was a mistake.  So, why don't we have  
anything like UPnP IGD and NAT-PMP for IPv6?  They're necessary for  
IPv4/NAT and we need them in IPv6 for the same reasons.  It seems  
like we ought to standardize them.

> I'm struggling with what's hard about that if you keep network  
> layer devices looking at the network layer and maybe the port  
> numbers from the transport header. Why do you want your firewall  
> mucking around inside your data?

Consider ISAKMP and IPsec for a moment.  An outbound ISAKMP  
initiation will create appropriate UDP state for port 500, but it  
won't do anything to permit inbound IPsec ESP packets for the  
corresponding SA to be delivered unless something in the stateful  
packet filter is reading the ISAKMP traffic and knows what inbound  
flows are expected to pass the filter.  (Truthfully, I don't think  
IPv6-PMP can solve this problem.  I'm going to have to write an  
ISAKMP proxy for that.)

The larger problem is that future application protocols may have  
similar issues with stateful packet filters.  Do we really want to  
limit the ability of application protocol designers to deploy new  
systems this way?  It seems to me that ICMP is the place where a  
solution to this problem should be applied.  I'm envisioning  
something very much like the way MLD messages are sent when a socket  
joins a multicast group.  Something like that could be done for  
unicast when a UDP socket is bound or a TCP socket is placed into the  
LISTEN state.  Default gateways would respond by opening the pinhole  
appropriately, and perhaps sending a similar ICMP message upstream to  
the next default gateway if necessary.


--
j h woodyatt <jhw@apple.com>