Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-06.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Apr 2007 10:14:00 +0200

James,

Thanks for your gracious comments. In turn, I'm sorry if my tone
was bit high. I've been living with this draft since 2004,
and it's hard to see it through other eyes.

    Brian

On 2007-03-29 19:25, james woodyatt wrote:
> On Mar 29, 2007, at 08:31, james woodyatt wrote:
>>
>> [...] I've had personal experience recently with exactly the sort of 
>> mistaken impression, which I mentioned in my first message, that I was 
>> concerned about.  That experience led me to take the very bold step of 
>> asking the authors to consider an editorial change to prevent what I 
>> thought were misunderstandings about the IETF consensus. [...]
> 
> I should explain that this experience was in the context of discussions 
> inside Apple about how best to respond to this:
> 
>     <http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1338>
> 
> Despite the referenced draft being informational, and despite the 
> caution in its introduction, and despite efforts to bring both these 
> facts to the attention of decision makers, the NAP draft has been 
> referenced as if it were an already published BCP.
> 
> I apologize again for not keeping up-to-date on the IETF consensus about 
> this issue.  When I last spent much time participating in IETF 
> discussions, this was the subject of a long-running and sometimes very 
> heated controversy.  I suppose I should be thankful that the controversy 
> has ended.
> 
> Again, my apologies all around.  I was trying to participate in good 
> faith.  I did not mean to arouse hostility and I'm mortified to have 
> done so.  I'd like to assure the working group that I'll make the 
> appropriate recommendations to decision makers at Apple about how to 
> proceed in compliance with the recommendations of the IETF.
> 
> 
> --james woodyatt <[email-masked]>
> member of technical staff
> apple inc.
> 
> 
>

---

From: james woodyatt <[email-masked]>
Date: Mon, 9 Apr 2007 17:39:30 -0700

On Mar 29, 2007, at 10:25, james woodyatt wrote:
>
> I'd like to assure the working group that I'll make the appropriate  
> recommendations to decision makers at Apple about how to proceed in  
> compliance with the recommendations of the IETF.

I have an update about this.  Today, Apple released the following  
article "About the security content of Firmware Update 7.1 for  
AirPort Extreme Base Station with 802.11n"

	<http://docs.info.apple.com/article.html?artnum=305366>

Here's the relevant section:
>> CVE-ID: CVE-2007-1338
>>
>> Available for: AirPort Extreme Base Station with 802.11n*
>>
>> Impact: AirPort Extreme Base Station with 802.11n* allows incoming  
>> IPv6 connections
>>
>> Description: The default configuration of an AirPort Extreme Base  
>> Station with 802.11n* allows incoming IPv6 connections. This may  
>> expose network services on hosts connected through an AirPort  
>> Extreme Base Station with 802.11n* to remote attackers. This  
>> update addresses the issue by changing the default setting to  
>> limit inbound IPv6 traffic to the local network. This issue only  
>> affects AirPort Extreme Base Station with 802.11n*, and not other  
>> versions of the Base Station.
>>
>> [...]
I'm still a little unclear about the rational arguments in favor of  
this behavior, but I've learned to stop asking dumb and annoying  
questions and to just do my job.

One concern I've been asked to think about is that the product  
doesn't offer any mechanism for nodes on the leaf network to request  
the opening of a pinhole in the stateful packet filter.  This  
function is performed in the IPv4 case by NAT-PMP (which Apple has  
tried to advance within IETF without much success), but there is no  
equivalent function for IPv6.  This was a deliberate decision on our  
part, but now we're left reconsidering it.

I know the world's experts on IPv6 operations are regular  
participants here, so I'm hoping the group will provide me with the  
clue that I'm trying desperately to catch.

As far as I know, there is no current or pending IETF standard for  
nodes to use in requesting open pinholes through the stateful packet  
filter in a residential IPv6 gateway.  In light of the IETF consensus  
noted earlier in this thread, doesn't that seems like a serious  
oversight?  Isn't this function something that rightfully belongs in  
ICMP6?  If not, do we really think extending NAT-PMP and UPnP IGD to  
support IPv6 network boundary filters is a good idea?  (A month ago,  
I would have found that hard to believe, but I've made some  
embarrassing mistakes lately, so I'm gun-shy about what I don't  
believe anymore.)

Incidentally, for those interested in the IPv6 behavior of this  
product, be advised that most IPv6 applications won't work in the  
default mode, i.e. with the stateful packet filter turned on.  For  
example, active mode FTP from the leaf network won't work, because  
the inbound TCP connection for the data will be blocked by the  
filter.  We haven't written any application layer gateways for the  
IPv6 filter in the AirPort Extreme base station, so things like SIP,  
RTSP, IPsec/IKE, etc. simply will not work at all.  I can't say when  
enhancements to support any of those application protocols will be  
available.  They'll have to be written one by one, and until  
recently, we mistakenly thought that the whole point of IPv6 was to  
make that unnecessary.  (Yeah, that'll teach me not to stay abreast  
of developments in the IETF.)

--
j h woodyatt <[email-masked]>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 10 Apr 2007 12:45:40 +0300

> clue that I'm trying desperately to catch.

With regards to stateful and inbound IPv6 firewalling, the v6ops NAP 
document says:

   To implement simple security for IPv6 in, for example a DSL or Cable
   Modem connected home network, the broadband gateway/router should be
   equipped with stateful firewall capabilities.  These should provide a
   default configuration where incoming traffic is limited to return
   traffic resulting from outgoing packets (sometimes known as
   reflective session state).  There should also be an easy interface
   which allows users to create inbound 'pinholes' for specific purposes
   such as online-gaming.

   Administrators and the designers of configuration interfaces for
   simple IPv6 firewalls need to provide a means of documenting the
   security caveats that arise from a given set configuration rules so
   that users (who are normally oblivious to such things) can be made
   aware of the risks.  As rules are improved iteratively, the goal will
   be to make use of the IPv6 Internet more secure without increasing
   the perceived complexity for users who just want to accomplish a
   task.

So... there seems to be a need for a mechaninism to open pinholes (I do 
not expect the average user be able to do that).

The hot debate around ICE & ANAT on MMUSIC at last IETF also hinted at 
IPv6 stateful firewalls, very much like IPv4 (though of course there 
should be no address/port translation).

> filter in a residential IPv6 gateway.

Neither have I seen any such work.

> In light of the IETF consensus 
> support IPv6 network boundary filters is a good idea?

I would rather define a sane way to do "hole punching" for 
connection-oriented protocol. We know how to establish a UDP (or 
UDP-Lite) flow between two IPv6 hosts both behind a stateful 
firewall... but somehow I am having a hard time buying the 
TCP "simultaneous open" idea.

I definitely agree we need something. I don't know PMP too well, but 
isn't it limited to one hop?

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Apr 2007 10:48:29 -0700

> not expect the average user be able to do that).

I feel confident saying that my employers will not expect its  
customers to manage firewall configuration manually.  They currently  
enjoy the automatic operation of NAT-PMP with IPv4/NAT and I have  
every reason to expect that an IPv6 version of PMP is what will end  
up happening unless there is a standard protocol to use instead.

> TCP "simultaneous open" idea.

I must say I'm surprised that a consensus has arisen around the need  
for stateful packet filtering at residential IPv6 gateways without  
there also being an effort underway to standardize the method for  
IPv6 nodes to solicit pinholes in them.  I'm sure I must have missed  
the discussions where the decision to defer this took place, but I'm  
someone knows where I can review the email archives.  Someone?

> isn't it limited to one hop?

Yes, it's limited to one hop, but it's the best we have, so that's  
what we do.  You can review the protocol specification here:

	<http://www.tools.ietf.org/html/draft-cheshire-nat-pmp>

This draft is now expired, and we are currently discussing whether  
and how to expand it for describing support for soliciting pinholes  
in IPv6 stateful packet filters at the default gateway.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 10 Apr 2007 22:13:02 +0300

Le mardi 10 avril 2007 20:48, james woodyatt a écrit :
> IPv6 nodes to solicit pinholes in them.

I am not so sure there is a "consensus" around the use of stateful 
firewalls for SOHO CPEs. As I understand v6ops-nap, it says: "if you 
want security equivalent to that of a NAT, you can use a stateful 
firewall, and hence you should not be afraid of IPv6". It does not 
say "you shall use a stateful firewall in any case". But of course, 
some people are going to do that, and "This wifi access point protects 
your computer" stickers look good on the shelves - even if users then 
disable the firewall because it breaks their favorite P2P app.

In fact, in the residential^Wunmanaged cases, one may well do with a 
host firewall, which is much easier and more efficient at mapping ports 
to applications, than any middlebox.

As far as I can tell, UPnP, NAT-PMP and the "DMZ" concept found in some 
cheap NATs are more about working around the private addressing 
problems, than security. In that sense, there is no need for them in 
IPv6 world.

I am still concerned that these stateful firewalls will be present in 
other types of access networks, and while UDP is quite easy to pass 
through with hole punching, TCP, SCTP and DCCP are almost impossible. 
That seems to be shrinking the added-value of IPv6, which is not 
something we (at least, I) want.

> I'm sure I must have missed 

Me too...

> in IPv6 stateful packet filters at the default gateway.

That's getting off-topic, but IMHO, it should be using official IP 
protocols numbers rather than assume TCP or UDP. I can count at least 
five IETF transport protocols to this day, all using the same port 
numbering/muxing mechanism. While I gave up hope of seeing them go 
through existing IPv4/NAT world (and I understand you can't break 
backward compatibility), I am still optimistic about IPv6.

Otherwise, it's appreciable that it seems to work (not assuming external 
port = internal port like UPnP) and not bloated (contrary to UPnP).

Regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Fred Baker <[email-masked]>
Date: Wed, 11 Apr 2007 05:37:28 +0800

> should be no address/port translation).

of course there will be stateful firewalls.

I compare this to the health management system of the human body.  
Apart from blood loss and things like that, the mechanisms that keep  
the body healthy would mostly do so without the skin. But the skin  
makes it ever so much more effective.

Firewalls that permit the end to end principle to remain in force are  
a good thing for networks. Where the so-called "personal firewall" on  
a desktop/laptop protects the system, the firewall protects the  
investment in the network and provides a second layer of defense for  
the host.

Doesn't SOCKS/GSSAPI open pinholes in firewalls?

And the stateful firewalls I am most familiar with actually open  
pinholes automagically. They observe SYN-etc messages going out and  
open pinholes for the responses. Where one needs to do more is with  
protocols where the originatig message is incoming. I would expect  
(in keeping with the stateful firewalls I am most familiar with) that  
this is done with an access list that allows SMTP to the incoming  
mail server, WWW to the web server, and so on. A SIP proxy can  
similarly open a pinhole for a SIP data call.

---

From: Mark Smith <[email-masked]>
Date: Wed, 11 Apr 2007 07:09:41 +0930

On Tue, 10 Apr 2007 10:48:29 -0700

> someone knows where I can review the email archives.  Someone?

Maybe I'm missing something, but couldn't the fatal problem be that one
piece of malware, delivered via an email attachment for example, that
the user is fooled into running, could open up a "pin-hole" that is large
enough to fly a jumbo jet through  (and drive a bus through, and sail a
super-tanker through, all at the same time) ?

Regards,
Mark.

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Apr 2007 15:01:12 -0700

On Apr 10, 2007, at 12:13, Rémi Denis-Courmont wrote:
>> I must say I'm surprised that a consensus has arisen around the  
>> need for stateful packet filtering at residential IPv6 gateways  
>> without there also being an effort underway to standardize the  
>> method for IPv6 nodes to solicit pinholes in them.
>
> firewalls for SOHO CPEs. As I understand v6ops-nap, it says: "if  
> you want security equivalent to that of a NAT, you can use a  
> stateful firewall, and hence you should not be afraid of IPv6". It  
> does not say "you shall use a stateful firewall in any case". [...]

As I noted earlier in this thread, section 4.2 of <http:// 
tools.ietf.org/wg/v6ops/draft-ietf-v6ops-nap-06/> says:

>>> To implement simple security for IPv6 in, for example a DSL or  
>>> Cable Modem connected home network, the broadband gateway/router  
>>> should be equipped with stateful firewall capabilities.  These  
>>> should provide a default configuration where incoming traffic is  
>>> limited to return traffic resulting from outgoing packets  
>>> (sometimes known as reflective session state).  There should also  
>>> be an easy interface which allows users to create inbound  
>>> 'pinholes' for specific purposes such as online-gaming.

At first, I thought this recommendation belonged in a BCP (i.e. that  
"may" would be better here than "should").  I was mistaken.

We have now heard from a member of the IESG that the paragraph quoted  
above represents the hard-fought consensus opinion of the IETF  
community, and I see no reason to question his authority on the  
matter.  Especially, since that opinion is completely in concurrence  
with similar recommendations from Microsoft, the U.S. Department of  
Homeland Security, and now my employers as well.  In addition, I have  
searched the last six months of mail archives of the V6OPS and IPV6  
working groups, as well as the archive of the IETF discussion group,  
and I have seen no sign of any controversy on this issue.

As far as I can see, the debate has concluded and the issue is settled.

Residential IPv6 gateways *will* implement stateful packet filters in  
their default configurations.  I'm not interested in reopening a  
debate over that proposition.  It's done.  All I need now is to  
figure out how to make IPv6 do what IPv4/NAT can do today by using  
either NAT-PMP or UPnP.

>> I'm sure I must have missed the discussions where the decision to  
>> defer this took place, but I'm [sure] someone knows where I can  
>> review the email archives.  Someone?
>
> Me too...

I've been searching and haven't found them yet.  Perhaps, this  
discussion took place at an IETF meeting and it was not recorded in  
the minutes?  Does anyone have any recollection about how this happened?

>> and how to expand it for describing support for soliciting  
>> pinholes in IPv6 stateful packet filters at the default gateway.
>
> protocols numbers rather than assume TCP or UDP. I can count at  
> least five IETF transport protocols to this day, all using the same  
> port numbering/muxing mechanism. While I gave up hope of seeing  
> them go through existing IPv4/NAT world (and I understand you can't  
> break backward compatibility), I am still optimistic about IPv6.

I wasn't involved in the drafting of the original NAT-PMP  
specification, but I was present for the reviews before it was  
published.  At the time, we didn't envision NAT-PMP as anything more  
than a transition mechanism for use only with IPv4.  To that end, we  
deliberately avoided making the protocol easily extended to support  
more than the limited functionality we felt was necessary to  
facilitate an orderly transition toward IPv6.

See section 4.2, which says:

>>> Any client making use of this protocol SHOULD implement IPv6  
>>> support.  If a client supports IPv6 and is running on a device  
>>> with a global IPv6 address, that IPv6 address SHOULD be preferred  
>>> to the IPv4 public address using this NAT mapping protocol. In  
>>> case other clients do not have IPv6 connectivity, both the IPv4  
>>> and IPv6 addresses SHOULD be registered with whatever form of  
>>> directory server is used. Preference SHOULD be given to IPv6  
>>> addresses when available. By implementing support for IPv6 and  
>>> using this protocol for IPv4, vendors can ship products today  
>>> that will work under both scenarios. As IPv6 is more widely  
>>> deployed, clients of this protocol following these  
>>> recommendations will transparently make use of IPv6.

Alas, we are now revisiting whether this was a realistic transition  
plan in light of the consensus that IPv6 gateways will encompass  
stateful packet filters that need to be solicited for pinholes just  
like an IPv4/NAT gateway does.

If extending NAT-PMP to support IPv6 is what needs to be done, then  
deliberately crippling the extensibility of the protocol to prevent  
it from being useful with transports and extension header types not  
currently defined is an obviously bad idea.  I feel safe assuring the  
working group that Apple is committed to the IETF process for  
advancing a standard protocol that the entire community supports.

This is why I am starting in the V6OPS working group.  If the  
membership here agrees that an operational problem exists that needs  
a standards effort to solve, then this is the place to make the basic  
decisions about where to begin.  Perhaps, extending ICMP is the right  
choice, in which case we should go to the IPV6 working group to  
begin.  Otherwise, perhaps NAT-PMP could be used as a template for  
devising a new and separate IPV6-PMP specification.  I'm not sure  
what working group would be the best choice for that work.

If IETF doesn't think a standard protocol is necessary, then Apple  
will probably be left to do something non-standard.  I hope that  
won't be necessary.

> Otherwise, it's appreciable that it seems to work (not assuming  
> external port = internal port like UPnP) and not bloated (contrary  
> to UPnP).

Thanks.  We try.

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Apr 2007 15:27:12 -0700

On Apr 10, 2007, at 14:37, Fred Baker wrote:
>
> Firewalls that permit the end to end principle to remain in force  
> are a good thing for networks.

Agreed.  Unfortunately, the default "firewall" in the initial version  
of AirPort Extreme base station was only a stateless one designed for  
the purpose of simply dropping packets that were obviously bogus from  
inspecting the headers.  It's still there, of course, but it's been  
enhanced in the default mode with a much more restrictive stateful  
one that must be turned off explicitly.  (Doing that is a complicated  
process that we expect most users will never do.)

Apple promptly responded to public concerns about the security risks  
associated with not enabling the stateful packet filter by default,  
but this has the side effect of not conserving the end-to-end  
principle.  The filter applies basically the same limitations on IPv6  
traffic as what network address translation demands from IPv4, i.e.  
inbound packets are only passed if they match state created by  
outbound flows.

> Where the so-called "personal firewall" on a desktop/laptop  
> protects the system, the firewall protects the investment in the  
> network and provides a second layer of defense for the host.
>

I don't think so.  My understanding of SOCKS is that it's for  
application layer proxies, not network layer stateful packet  
filtering firewalls.  I could be wrong.

> (in keeping with the stateful firewalls I am most familiar with)  
> that this is done with an access list that allows SMTP to the  
> incoming mail server, WWW to the web server, and so on. A SIP proxy  
> can similarly open a pinhole for a SIP data call.

The problem arises when a new application protocol is deployed for  
which an application layer gateway has not been implemented in the  
stateful packet filter of the IPv6 gateway.

I can easily write an ALG for the file transfer protocol that  
inspects the FTP control stream for the PASV and PORT commands and  
punches pinholes for the inbound TCP data connection.  In fact, it's  
on my short list of immediate things to do.  This is a  
straightforward adaptation of the existing FTP ALG in our IPv4/NAT.   
I can do the same thing for SIP, and BitTorrent, and ISAKMP, and,  
and, and... but how do I support application protocols that haven't  
been designed yet?

What can we do to make it so new applications can be deployed over  
IPv6 without requiring the ALG set in stateful packet filters on  
every gateway to be upgraded to support them before they will work?   
I don't see how that can be accomplished without something that  
allows IPv6 nodes to solicit the packet filter to create a rule for  
allowing inbound flows to create state.  This facility exists today  
with IPv4/NAT through UPnP and NAT-PMP.  It's not there for IPv6 as  
far as I can tell.

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Apr 2007 15:35:25 -0700

On Apr 10, 2007, at 14:39, Mark Smith wrote:
>
> Maybe I'm missing something, but couldn't the fatal problem be that  
> one piece of malware, delivered via an email attachment for  
> example, that the user is fooled into running, could open up a "pin- 
> hole" that is large enough to fly a jumbo jet through  (and drive a  
> bus through, and sail a super-tanker through, all at the same time) ?

You'd think so, but the U.S. Department of Homeland Security didn't  
have jack to say about the fact that the AirPort Extreme base station  
ships with NAT-PMP enabled in its default mode.  Apparently, it's the  
solicitation that makes the difference.  As long as the local node is  
only globally exposed as a result of its explicit and deliberate  
solicitation of the default gateway, that seems to make all the  
security experts happy.

I don't understand why this should be, but then I'm only an egg.   
People much smarter than me have made these decisions, and they don't  
like nitpickers second-guessing them about it.

---

From: Fred Baker <[email-masked]>
Date: Wed, 11 Apr 2007 09:43:25 +0800

> filtering firewalls.  I could be wrong.

It does indeed. I guess I thought that was what you were asking for  
in addition to what a stateful firewall does automagially.

>> pinholes automagically. They observe SYN-etc messages going out  
>> and open pinholes for the responses. Where one needs to do more is  
>> with protocols where the originatig message is incoming. I would  
>> expect (in keeping with the stateful firewalls I am most familiar  
>> with) that this is done with an access list that allows SMTP to  
>> the incoming mail server, WWW to the web server, and so on. A SIP  
>> proxy can similarly open a pinhole for a SIP data call.
>

hmm. I wasn't aware that application layer gateways were required.  
The one I am most familiar with has options for ALGs, but absent them  
simply allows you to say things like

	ip access-list permit smtp any host smtp.example.com

That done, TCP port 25 traffic from anywhere to the system  
smtp.example.com goes through the firewall. Assuming that's your  
preferred incoming MTA, that's all the pinhole you need.

> punches pinholes for the inbound TCP data connection.

	ip access-list permit ftp any host ftp.example.com
	ip access-list permit ftp-data any host ftp.example.com

In the other direction, the stateful firewall already does what you  
want. It observes the outgoing SYN and temporarily opens up to accept  
the corresponding SYN-ACK. That does't handle ACTIVE FTP, but PASSIVE  
works fine.

> In fact, it's on my short list of immediate things to do.  This is  
> a straightforward adaptation of the existing FTP ALG in our IPv4/ 
> NAT.  I can do the same thing for SIP, and BitTorrent, and ISAKMP,  
> and, and, and... but how do I support application protocols that  
> haven't been designed yet?

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?

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Apr 2007 19:32:12 -0700

> 	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.

---

From: Gert Doering <[email-masked]>
Date: Wed, 11 Apr 2007 08:14:14 +0200

Hi,

> of end-to-end goodness restored to the Internet.

While I read your words, and understand the situation, I actually fail
to understand the IPv6 situation.

Adapting the description above to IPv6 would mean something like this:

 - as soon as a program calls listen() to setup a socket for incoming
   IPv6 connections, the OS would notify the "firewall thing" that these
   packets should be let in
 - everything that has no process listening for it (or is not a response
   packet to an outgoing connection) is dropped by the "firewall thing"

Now - if you just shut down the IPv6 filter on the firewall, what you
get is:

 - as soon as a program calls listen() to setup a socket for incoming
   IPv6 connections, the OS would start accepting these packets, instead
   of sending "TCP RST" or "UDP port unreachable"
 - everything that has no process listening for it (or is not a response
   packet to an outgoing connection) is dropped by the host's TCP/IP stack

For IPv4/NAT you actually need to notify the "firewall thing" of desired
connections (because it needs to know *which* host on RFC space to forward
the packets to), but in the model above, the "IPv6 firewall thing" would
actually 

 - refuse packets that would be dropped at the host anyway
 - forward everything that the host would handle, with no idea about
   the legitimacy of the application (read: it would let through connections
   to trojan backdoors etc. as well, as the OS can't know that their
   listen() request ist "bad")

So what am I missing here...?

[..]
> like we ought to standardize them.

*If* you have a stateful IPv6 filter in the default gateway, and want
to have it work without manual configuration for incoming connections,
then indeed, you need something like "PMP IPv6".

OTOH I'm not sure what the benefit of an IPv6 filter in this scenario is,
if it is auto-deactivated for all interesting traffic anyway...

(Yes, I know.  People will yell at you if you don't have "IPv6 firewall!!"
on the product's data sheet.  But some half-informed people will yell at 
you anyway... :( )

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  113403

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 11 Apr 2007 10:52:01 +0300

Le mercredi 11 avril 2007 09:14, Gert Doering a écrit :
(...)
> For IPv4/NAT you actually need to notify the "firewall thing" of
> desired connections (because it needs to know *which* host on RFC
> space to forward the packets to), but in the model above, the "IPv6
> firewall thing" would actually
>
>    the legitimacy of the application (read: it would let through
> connections to trojan backdoors etc. as well, as the OS can't know
> that their listen() request ist "bad")
>
>

That's also what I understand.

> > 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.
>
> to have it work without manual configuration for incoming
> connections, then indeed, you need something like "PMP IPv6".
>
> OTOH I'm not sure what the benefit of an IPv6 filter in this scenario
> is, if it is auto-deactivated for all interesting traffic anyway...

I somehow agree: Personnal firewalls are better suited, all the more 
since software vendors cannot assume that there is an edge firewall, so 
they can't make their product security rely on this.

However:
- in some scenarios, you want to drop unsolicited traffic early (e.g. if 
the last mile is some bnadwidth-challenged radio technology),
- some programs that are only supposed to serve the LAN won't open 
pinhole (yeah, I just said that was lame in the previous paragraph),
- many people seem to think that a disaster will happen if the NATs side 
effect security vanishes, and they won't switch to IPv6 if there is 
no "stateful firewall" (regardless of the fact that most malware is now 
transmitted through upper layers that won't care about stateful 
firewalls).

> (Yes, I know.  People will yell at you if you don't have "IPv6
> firewall!!" on the product's data sheet.  But some half-informed
> people will yell at you anyway... :( )

Hmm, some product managers in NetworkBoxCorp will read that IPv6 CPEs 
need a "stateful firewall" because IETF said so. So they'll put it to 
the requirements list, and voilà, it has to be there in every IPv6 
CPEs.

And then, IPv6 is completely useless, since it has the exact same 
connectivity problems as IPv4+NAT: outbound TCP works; UDP works 
through hole punching if you know the peer address/port. Inbound TCP 
does not work (so COMEDIA SIP does not), unsolicited UDP does not work. 
So IPv6 becomes pretty useless, while it remains very costly an 
upgrade.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: james woodyatt <[email-masked]>
Date: Wed, 11 Apr 2007 10:08:40 -0700

>    packet to an outgoing connection) is dropped by the "firewall  

That's the general idea.  I can easily imagine some very sensible  
constraints on that, but you have the basic idea.

> if it is auto-deactivated for all interesting traffic anyway...

The phrase I keep hearing from the security experts is a "multi- 
layered barrier" system.

> people will yell at  you anyway... :( )

Do *NOT* underestimate the power of those people.  When the U.S.  
Department of Homeland Security issues a CyberAlert, and when a  
Google News search on "ipv6 airport" returns fifty technical  
publications announcing that you have shipped a product that exposes  
networked computers to remote attack over IPv6, and you have senior  
vice presidents demanding a prompt response to all these security  
advisories that have put the trade press into a frenzy, then I'd like  
to see how far *you* get explaining that "some half-informed people  
will yell" but they should just be ignored.

I tried that.  (Yes, I'm that stupid.)  It didn't work.  Now, I'm  
trying to find a way to make IPv6 at least as useful as IPv4/NAT.   
I'm hoping to find some help with that here in the V6OPS working group.

---

From: james woodyatt <[email-masked]>
Date: Wed, 11 Apr 2007 10:21:50 -0700

On Apr 11, 2007, at 00:52, Rémi Denis-Courmont wrote:
> - many people seem to think that a disaster will happen if the NATs  
> side effect security vanishes, and they won't switch to IPv6 if  
> there is  no "stateful firewall" (regardless of the fact that most  
> malware is now transmitted through upper layers that won't care  
> about stateful firewalls).

I'm trying to find somebody with some technical expertise, and who  
can speak authoritatively on the subject, who *DOESN'T* believe this.

+ Microsoft's recommendations for Internet gateway device  
implementers call for this.
+ The NAP draft in this working group calls for this, and I'm told  
this the result of an IETF consensus.
+ Apple received nothing but negative criticism for shipping AirPort  
Extreme without this side effect on the IPv6 side.  (The U.S.  
Department of Homeland Security called it a "design error".)

Is there anyone on the IESG or the IAB who will speak up about this?   
Anyone?  You'll forgive me if I don't hold my breath.

> Hmm, some product managers in NetworkBoxCorp will read that IPv6  
> CPEs need a "stateful firewall" because IETF said so. So they'll  
> put it to the requirements list, and voilà, it has to be there in  
> every IPv6 CPEs.

This has already happened.  I was in the room.

Worse, the security team at $CORPORATION has issued a security  
advisory to the effect that not having the "stateful firewall"  
enabled exposes local network nodes to remote attack and instructs  
customers to take steps to enable it, and changed the factory  
configuration to match the advised behavior.  This means that every  
box from $CORPORATION for the foreseeable future will ship with the  
"stateful firewall" enabled in the default configuration, and users  
will never be comfortable turning it off.  Indeed, the manufacturer  
is advising them *not* to turn it off.

This isn't hypothetical.  It's the reality today.

> through hole punching if you know the peer address/port. Inbound  
> TCP does not work (so COMEDIA SIP does not), unsolicited UDP does  
> not work.  So IPv6 becomes pretty useless, while it remains very  
> costly an upgrade.

Unless we do something.  I'm proposing that we consider extending  
ICMP to support automatically opening pinholes in the default  
gateway's stateful packet filter.  Does anybody have any alternative  
to consider?

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 11 Apr 2007 21:11:01 +0300

Hello,

> makes it ever so much more effective.

I don't ask my parents or the local police officer to protect me from 
microbes and bacterias... I use my own skin, and similarly my PC has 
its own firewall that knows much better what it should pass and what it 
should keep out than my CPE. And even if the CPE knew (we just agreed 
this is currently impossible in the listening TCP port case...), I 
would not expect it to keep up with software upgrades on every single 
IPv6-capable software I might ever install on any of my IPv6-capable 
devices.

> a good thing for networks.

Sure, but I don't know any such firewall. And the typical stateful 
firewall allowing everything out and nothing unsolicited in DEFINITELY 
DOES NOT respect the end-to-end principle. Try to establish a COMEDIA 
SIP session with such a thing <-- this is a very basic benchmark for 
IPv6 to have any practical advantage over IPv4+NAT.

> Where the so-called "personal firewall" on a desktop/laptop protects
> the system, the firewall protects the investment in the network

The "investment" in the typical household network is a WiFi+Ethernet 
switch and a few Cat-5 cables. The switch can drop anything packet sent 
to its address from the outside. Cables don't need protection. Every 
thing else has its personal firewall.

> Doesn't SOCKS/GSSAPI open pinholes in firewalls?

AFAIK, SOCKS creates *outbound* connections when there is no routing at 
all.

> open pinholes for the responses.

With all due respect, that's nonsense. The passive side of a TCP 
connection does not send anything until it received a packet from the 
foreign peer. Stateful firewalls block exactly that.

With stateful firewalls everywhere, we are back to a full 
client-server-only Internet. That happens to work very well with IPv4 
already. What would anyone switch then?

> A SIP proxy can similarly open a pinhole for a SIP data call.

So I have to upgrade my (supposedly dirty cheap) CPE every time I want 
to use a new protocol. That's not at all end-to-end principle as far as 
I understand it.

Regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 11 Apr 2007 22:14:27 +0300

> gateway's stateful packet filter.  Does anybody have any alternative

I guess everybody agrees that stateful firewalling won't go away with 
IPv6, whether one likes it or not (I'm obviously not a big fan of 
them). That kills the "no firewall so no problem" alternative. Then, 
the only alternatives are the big broken heavyweight solution (à la 
UPnP) ;) I definitely prefer the lightweight one that actually works.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: james woodyatt <[email-masked]>
Date: Wed, 11 Apr 2007 12:27:47 -0700

On Apr 11, 2007, at 12:14, Rémi Denis-Courmont wrote:
>> gateway's stateful packet filter.  Does anybody have any  
>> alternative to consider?
>
> I guess everybody agrees that stateful firewalling won't go away  
> with IPv6, whether one likes it or not (I'm obviously not a big fan  
> of them). That kills the "no firewall so no problem" alternative.  
> Then, the only alternatives are the big broken heavyweight solution  
> (à la UPnP) ;) I definitely prefer the lightweight one that  
> actually works.

For the record, I've not received any off-list messages to explain  
how the IETF managed to arrive at a consensus about the need for  
stateful IPv6 packet filters in default gateways while deferring  
efforts to define a standard method for nodes to solicit pinholes  
through them.  I continue to search the email archives for signs of a  
discussion about this, and I have not found anything.  My requests  
that someone come forward with recollections of a discussion in a  
meeting session, which I'm assuming went unrecorded in the minutes,  
has gone unanswered.

This is almost too much for me to believe.  I'm beginning to suspect  
I'm being set up to be the butt of an elaborate practical joke.  I  
know I have a reputation for being an entertaining target for such  
japes, but I hadn't thought that reputation could precede me into  
groups like this one.  I should probably feel flattered, I guess.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Apr 2007 14:01:38 -0700

> through them.

I don't think there ever was an IETF recommendation about this. What happened is more a recognition that the "no firewall -- no problem" approach won't be accepted in practice. While modern PC's and MAC's ship with a OS firewall, there are many other devices on home networks. These other devices often make the hypothesis that the home network is safe, and expect to be "protected". The vendors of gateway devices don't believe they can market a "no firewall" solution.

Apple's PMP effort tries to solve the same problem that Microsoft addressed with the UPNP profile for gateway devices in 2001. The main difference between the two approaches is the use of an XML framework in UPNP, versus short binary messages in PMP. Both designs seem to have the same security model, i.e. none besides verifying that the host is actually inside the home network. Rémi Denis-Courmont mentioned the alleged brokenness of the UPNP design, but in fact the main criticism against the UPNP solution is this security model, shared by Apple's PMP.

In any case, the BEHAVE working group is chartered to deal with this issue, and would be a better place for the discussion.

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Wed, 11 Apr 2007 14:08:54 -0700

On Apr 11, 2007, at 14:01, Christian Huitema wrote:
>
> In any case, the BEHAVE working group is chartered to deal with  
> this issue, and would be a better place for the discussion.

Thank you!  That's the information I was trying to surface.  I'll  
bring this discussion over there.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 12 Apr 2007 22:08:30 -0400

> In any case, the BEHAVE working group is chartered to deal with this
> issue, and would be a better place for the discussion.

Is it? Seems to me the IETF has historically shied away from firewall
configuration and recommendation issues.

Consider for instance the recent draft NIST IPv6 profiles
(http://www.antd.nist.gov/usgv6-v1-comments.html). They had to make up
their own "Network Protection Device" profile because there wasn't
anything from the IETF they could cite.

Given that reality that home gateways sitting on broadband links
_will_ have firewalls in them, and they _will_ be enabled by default,
maybe we should (even at this late date) try to rectify things for
IPv6.

As much as I am no fan of NAT, NAT is made even worse by the lack of
standards and predictability in what has been deployed.

Will we see the same with firewalls? This is an important question,
given that a premise of IPv6 is to restore end-to-end addressing. We
won't see that if firewalls effectively block all inbound connections
by default.

Thomas

---

From: james woodyatt <[email-masked]>
Date: Fri, 13 Apr 2007 11:49:40 -0700

On Apr 12, 2007, at 19:08, Thomas Narten wrote:
>
> As much as I am no fan of NAT, NAT is made even worse by the lack  
> of standards and predictability in what has been deployed.
>
> given that a premise of IPv6 is to restore end-to-end addressing.  
> We won't see that if firewalls effectively block all inbound  
> connections by default.

End-to-end addressing isn't going away unless the various open  
threats of IPv6 NAT get more traction, which I don't yet see  
happening.  (At the moment, I can only think of one compelling reason  
to implement IPv6 NAT, and I don't consider it a particularly big  
threat because I don't see it actually destroying end-to-end  
addressing.  It will happen, though.  In fact, it's on my medium-term  
list of things to do, mainly because otherwise I don't have a good  
mechanism for redirecting IPv6 flows into application layer gateways.)

I think it's reasonable to expect that if IETF doesn't produce a  
standard for endpoint nodes to signal routers (any of which may or  
may not be comprised of stateful packet filters) of their expectation  
to receive incoming flow initiations, then Apple will probably decide  
to implement something non-standard, of its own invention, and ship  
it without waiting for the blessings of IETF.  It's not like we  
haven't done that before.  In the IPv4/NAT case, the behavior we need  
today is implemented by NAT-PMP (and UPnP IGD), and now we need  
something like it for IPv6.

NAT-PMP was always intended to be a transition mechanism until IPv6  
could replace it. IPv6 cannot replace IPv4/NAT until this deficiency  
is remedied.  Whatever mechanism is developed to address this problem  
will be-- no joke-- with us for the next thousand years, so we  
obviously think a naïve adaptation of NAT-PMP to IPv6 would be  
suboptimal.

Alas, however, if that's what gets the problem solved...

---

From: james woodyatt <[email-masked]>
Date: Fri, 13 Apr 2007 13:43:01 -0700

> We won't see that if firewalls effectively block all inbound  

Is now a good time to suggest that perhaps one of the currently  
reserved bits in the ICMPv6 router advertisement should be consumed  
now to signal to nodes that the advertising router comprises a  
network policy enforcement point?  I see that draft-ietf-ipv6-2461bis  
is already in the RFC Editor's queue, but perhaps it could be yanked  
out and subjected to further revision.  If we do this, then nodes  
could at least know that inbound flow initiations might be  
administratively prohibited.  It would also clearly mark any routers  
that enforce policy without setting the "policy enforcement" bit in  
their router advertisements as non-compliant with the IPv6 standard.

---

From: Mark Smith <[email-masked]>
Date: Sun, 15 Apr 2007 09:59:25 +0930

Hi,

On Fri, 13 Apr 2007 11:49:40 -0700

> mechanism for redirecting IPv6 flows into application layer gateways.)

Are you able to clarify the above a bit further? Are you saying
that you're planning on implementing NAT for IPv6, so that you can
"transparently" intercept connections/flows and have them processed by middle
boxes in the network ?

<snip>

Thanks,
Mark.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 16 Apr 2007 10:22:24 +0300 (EEST)

On Fri, 13 Apr 2007, james woodyatt wrote:
> I think it's reasonable to expect that if IETF doesn't produce a standard for 
> endpoint nodes to signal routers (any of which may or may not be comprised of 
> stateful packet filters) of their expectation to receive incoming flow 
> initiations, ....

At least NSIS WG has been working on this (AFAICS; I haven't 
participated in the WG), see 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-14.txt

However, I'm personally somewhat doubtful on how much traction that 
effort is going to get.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: james woodyatt <[email-masked]>
Date: Mon, 16 Apr 2007 11:37:25 -0700

On Apr 14, 2007, at 17:29, Mark Smith wrote:
> "transparently" intercept connections/flows and have them processed  
> by middleboxes in the network?

Yes.  I have to do this to make application layer gateways (ALG) for  
IPv6 to be fully transparent.  There are a lot of well-known problems  
with trying to make ALG's operate on a packet-by-packet basis in the  
IP filter before the TCP stack can reassemble the octet-stream.  It's  
not too bad for FTP, but it's really perilous when you're trying to  
handle RTSP and other applications that have complicated interactions  
between application layers and the network layer.

I figure while I'm doing that, I might as well write a general  
purpose IPv6 NAT.  I wish I didn't have to do this, but the security  
considerations are pushing me into it.

---

From: james woodyatt <[email-masked]>
Date: Mon, 16 Apr 2007 11:43:51 -0700

On Apr 16, 2007, at 00:22, Pekka Savola wrote:
>> may not be comprised of stateful packet filters) of their  
>> expectation to receive incoming flow initiations, ....
>
> participated in the WG), see http://www.ietf.org/internet-drafts/ 
> draft-ietf-nsis-nslp-natfw-14.txt
>

I'm circulating that draft around inside Apple.  One obvious thing  
about it is that it's currently IPv4-only.  I think it might be more  
appropriate to extend NSLP for IPv6 than it is to extend NAT-PMP for  
IPv6, which we would certainly find a lot easier to do.  Alas, I  
don't know how much traction NSLP will get here.

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Apr 2007 06:16:41 +0930

Hi,

On Mon, 16 Apr 2007 11:37:25 -0700
james woodyatt <[email-masked]> wrote:

> IPv6 to be fully transparent.

They won't be "fully transparent". The devices on the public side of
the NAT will be able to detect them, or conversely, will break because
those devices or applications assume (quite reasonably, because that's
the (IPv6) Internet architecture) that there is a one-to-one mapping
between a network layer device and address.

Having had to deal with the problems that "transparent" ALG devices
cause at the network layer, I don't want to see them again. e.g.
traceroute doesn't show the path the traffic is actually taking, they
create performance bottle necks, you have to traffic engineer certain
traffic to always pass a certain point in the network so that the ALG
gets a look at it, they create problems with remote websites and
applications that very reasonably assume a one-to-one mapping between
an IP address and a user.

>  There are a lot of well-known problems  

Can you describe some of those interactions ? As far as I'm aware RTSP,
as do other applicaton protocols above the transport layer, just use IP
as a dumb packet transport between specified IP addresses.

> considerations are pushing me into it.

Can you detail those security considerations ? I'd find it hard to
believe that NAT is the only security technique (and personally I don't
really consider it to be one anyway) that solves your problem. What
unique property does NAT provide that no other alternative (such as
stateful firewalling with public addressing) doesn't? 

Regards,
Mark.

---

From: james woodyatt <[email-masked]>
Date: Mon, 16 Apr 2007 15:55:16 -0700

On Apr 16, 2007, at 13:46, Mark Smith wrote:
> On Mon, 16 Apr 2007 11:37:25 -0700, james woodyatt <[email-masked]>  
> wrote:
>>

p1. The mapping between nodes and addresses is already not one-to-one.

p2. I don't see the NAT required for IPv6 ALG's as breaking end-to- 
end addressability.

Whether network policy permits application reachability is  
independent of whether applications are addressable.  I only think  
NAT needs to be used to redirect application flows between  
middleboxes, not between application endpoints in separate addressing  
realms.

> gets a look at it, [...].

If stateful packet filters are widely deployed in residential IPv6  
gateways and turned on in the factory default mode, I can only see  
one way to make some of those problems avoidable: by defining  
something as a bump-in-the-stack that uses a yet-to-be-defined ICMP  
subprotocol for signaling application listeners to the packet filters  
in the path, and rolling that out everywhere in the Internet instead.

Personally, I think this alternative makes better sense over the very  
long term, but my experience is that the very long term always comes  
at a lower priority than the end of the current financial quarter.

> [...] they create problems with remote websites and

Yeah, but there are security considerations there.  RFC 3041 is an  
effort to address some of those, and not in a way that will make it  
*easier* for remote websites to continue assuming a one-to-one  
mapping between IP addresses and users.  This was always a dumb  
assumption, and it will only get dumber with IPv6, no matter what we  
do to resolve the problems I'm trying to highlight here.

> as a dumb packet transport between specified IP addresses.

Sure.  Both the RTSP client and server write IP address and UDP port  
numbers for the RTP and RTCP flows into the RTSP headers.  The  
stateful packet filter that blocks incoming flows will need to  
inspect the SETUP method and search for the "Transport:" headers,  
parse them for the source, destination, client_port and server_port  
attributes, and open/close pinholes for them as needed.

There are other applications, I'm sure, that have similar problems.   
As noted, ISAKMP/IKE is one of them unless ESP encapsulation in UDP  
is used in conjunction with some kind of ICE-like UDP probing scheme  
to keep the outbound UDP pinhole open while incoming UDP/ESP- 
encapsulated flows might be received.

I'm pretty sure that BitTorrent is another such application.  Also,  
I'm given to understand that some VoIP applications may be broken by  
the stateful packet filtering IETF recommends unless there is an ALG  
present for the application.

> stateful firewalling with public addressing) doesn't?

I only *NEED* the NAT to redirect flows into transparent ALG's to  
support the stateful packet filter.  (I'd say it's the market that  
seems unconvinced-- despite the laudable efforts of the authors of  
the NAP draft-- that IPv6 is sufficient for their needs without  
general purpose NAT being available, but that's not really my concern.)

I'm considering the task of writing a general purpose IPv6 NAT because:

1) I now have to maintain a full suite of ALG's for both IPv4 and IPv6;

2) I've got a collection of IPv4 ALG's already that depend on NAT to  
work;

3) I will still have support IPv4/NAT for the foreseeable future;

Therefore... the easiest way forward for me is the shortest path: by  
extending my general purpose IPv4 NAT to support IPv6.  It saddens me  
to have to do it, but there it is.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Apr 2007 10:32:48 +0200

On 2007-04-17 00:55, james woodyatt wrote:
...
> Whether network policy permits application reachability is independent of whether applications are addressable.  I only think NAT needs to be used to redirect application flows between middleboxes, not between application endpoints in separate addressing realms.

Can you explain that? Why can't you redirect packets without NAT?
Can you draw the picture? You could surely redirect by
encapsulation, and possibly by using a host route.

    Brian

---

From: [email-masked]
Date: Tue, 17 Apr 2007 03:09:10 -0600

> I only *NEED* the NAT to redirect flows into transparent ALG's to support > the stateful packet filter. (I'd say it's the market that seems
> unconvinced-- despite the laudable efforts of the authors of the NAP 
> draft-- that IPv6 is sufficient for their needs without general purpose
>  NAT being available, but that's not really my concern.) 
>
> 2) I've got a collection of IPv4 ALG's already that depend on NAT to work; 
>
> extending my general purpose IPv4 NAT to support IPv6. It saddens me to 
> have to do it, but there it is.

If I understand what you are trying to do, you want to take the end-to-end 
connectivity of IPv6 and break it in order to support applications that are 
running on multiple machines (thus IP addresses) just like the work around 
that was developed in IPv4 rather than having a load sharing or other device 
in front of the servers that would balance them on the back end? 

This does not sound like an IP layer problem but a problem in the 
applications you are trying to support.

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Apr 2007 21:40:01 +0930

On Mon, 16 Apr 2007 15:55:16 -0700

> p1. The mapping between nodes and addresses is already not one-to-one.

Which is really one of the fundamental reasons why IPv6 exists. Mapping
between nodes and addresses isn't one-to-one anymore because of NAT.

The network layer of the Internet (and DECNET, Appletalk, IPX and CLNS
etc.) were designed with the basic property that all nodes attached to
the same network would have unique and individual addresses.

The key property that unique and individual addresses gives a device
that is a "member" of a network layer is the equal ability to send and
receive packets to any of the other members of the network. The true
nature of network layers is peer-to-peer. Whether the target node
decides to process or ignore the received packet is up to the
individual and unique target node.

It is only the application architecture that defines whether a node is
performing a "client" or "server" role. Even then, that isn't a network
layer node classification - if I run a webserver and a web client on
the same node, as separate processes, you can't then point to that box
and say "its a server" or "it's a client".

The most common form of NAT, port translation, takes away the peer
property of the network layer devices, and that is why time and
resources have had to be spent developing NAT workaround mechanisms
such as STUN, for applications whose best suited architecture is
peer-to-peer. It would be better if the time and resources developing
and implementing mechansims such as STUN could have been spent on
adding functionality to the application, or debugging it further,
rather than working around a limitation in the network layer that
wasn't originally there or intended to be there.

Most applications, up until the predominance of NAT, also made the
assumption that a network layer address uniquely identified a member of
the network layer. 1-to-1 NAT breaks that, and so it breaks those
applications. Again, time has to be spent implementing work arounds in
applications that are being caused by a limitation in the network
layer. And again, there would be other things that the time and
resources could be better spent on.

IOW, the IPv4+NAT network layer is broken, but people are being forced
to work around those faults in the applications. 

Fixing the problem properly means fixing it where it is occuring. IPv6,
by restoring network layer addressing uniqueness, fixes the IPv4+NAT
problem where it's occuring - at the network layer.

> p2. I don't see the NAT required for IPv6 ALG's as breaking end-to- 

If the source or destination addresses are changed within the network,
rather than being preserved fully end-to-end (or network edge to network
edge - where the traffic sinks and sources exist), and that is what NAT
does, then NAT is breaking end-to-end addressability.

> middleboxes, not between application endpoints in separate addressing  

This sounds a bit to me as though the network layer is the incorrect
layer to be trying to solve this problem. The middlebox I'm guessing
you're talking about are things like application load balancers. It
would seem to me that the better way to solve high end application
performance and availability is build things such as CPU/Memory sharing
in the end node operating system. Technologies such as mainframes, or
commodity hardware with an OS that supports a "single system image"
across multiple machines would be a better fit for this sort of problem.

> in the path, and rolling that out everywhere in the Internet instead.

I think a better way to solve this problem is to have firewalls on each
node, rather than within the network. You don't need to worry about
openning pin-holes in an upstream device if the only thing that "doesn't
have the pin-hole" is the node itself.

Have a read of Steve Bellovin's paper, "Distributed Firewalls", which
details the idea of end-node firewalling. It's the place I first came
across the idea.

http://www.cs.columbia.edu/~smb/papers/distfw.html

Since I read that paper a number of years ago, an intersting thing has
happened - all major end-node OSes come out of the box with firewalls
installed and enabled.

I think a good way to think about end-node firewalling is to use the
truism, "if you want something done properly, you need to do it
yourself". Nodes that are attached to networks can't trust that there
is going to be an upstream device that is going to protect them, and
the only way they can get protection is to do it themselves. Once
they're doing it themselves, there isn't any need to develop any PMP
protocols, because there doesn't need to be an upstream protection
device. Having per-end node firewalls also makes all the end-nodes more
resilient - if a peer on the subnet is compromised, exploited or
attacked, that doesn't in anyway weaken other node's protections. The
same certainly can't be said about upstream network located firewalls.

> do to resolve the problems I'm trying to highlight here.

I completely disagree. As I mentioned before, every network layer
protocol ever designed has had the per-node uniqueness property.
Uniqueness of addressing is a requirement for unicast communication to
take place with any chance of success.

> present for the application.

All these complications disappear once the end-node running the
application is the same node that is taking ownership if its own
protection. 

> to have to do it, but there it is.

The question I ask is do you have to solve your problems when using
IPv6 exactly the same way you've had to solve them when using IPv4 ?
Yes, IPv4 and IPv6 are similar enough that a fair number of IPv4
solutions can be directly moved to IPv6 by just replacing the
addressing. But IPv6 is also different enough that inherent constraints
that IPv4 created, which then limited possible solutions, may not
exist. As a couple of examples, unique local unicast addressing
wouldn't be possible to implement in IPv4, and neither would HIP. 

Regards,
Mark.

---

From: Ed Jankiewicz <[email-masked]>
Date: Tue, 17 Apr 2007 11:43:27 -0400

Just a thought - IPv6 already allows for several kinds of multicast.  
Could an "equicast" (equitable load-balancing anycast - exactly one of 
the listeners responds to pending messages in turn when available) be a 
simple solution to load balancing?  An analog would be the one long 
queue in the airport served by many agents. (Obviously I'm just waiving 
my hands here, there would be some knotty issues like who maintains the 
queue of packets, and how do the servers coordinate saying "next?", what 
to do when no server is available after a timeout.  Definitely sounds 
like an application rather than IP solution.)

I don't want to trigger a debate on this, it is a good candidate for 
halfbakery.com so just take it as food for thought rather than a chance 
to shoot holes in swiss cheese.  But if anyone is aware of serious work 
on this kind of approach I'd be curious.

Ed J.

---

From: james woodyatt <[email-masked]>
Date: Tue, 17 Apr 2007 11:58:53 -0700

On Apr 17, 2007, at 01:32, Brian E Carpenter wrote:
>> middleboxes, not between application endpoints in separate  
>> addressing realms.
>

The immediate visibility of the problem is as an implementation  
concern for the existing AirPort Extreme base station product, where  
the NAT would be used only within the router itself, though I can  
imagine more complicated application level gateway deployments that  
might require the NAT to redirect from the filtering router to a  
proxy running on another middlebox.

Here's the current situation inside the AirPort Extreme base station:

+ We have an IPv4 packet filter with an integrated NAT.  The way the  
FTP and RTSP gateways are implemented is that NAT redirection rules  
are applied to the local interface to translate all outbound flows  
from FTP control streams and RTSP streams into a locally running  
proxy service.

+ The proxy service accepts these translated TCP streams and makes  
outbound connections on the client's behalf to the remote server.  In  
the IPv4 case, it translates IP addresses in the FTP control stream.   
It also inserts and removes state records for the FTP data streams it  
learns about in the process.  The equivalent things happens in the  
RTSP proxy.

+ To make this work with IPv6, the proxies don't have to translate  
anything, but they do still need to insert and remove state records  
for the associated TCP and UDP flows they learn about from parsing  
the FTP and RTSP streams.

+ The piece that's missing is the IPv6 NAT, to redirect FTP and RTSP  
control streams into the proxies.

> Can you draw the picture?

Here's a crude attempt at a picture of what's going on inside the  
router for the RTSP case, which is what allows Quicktime Streaming  
and RealPlayer streaming to use RTCP/RTP transports:

   Outbound TCP port 7070 SYN       Arrives on LAN 2001:db8:aaaa::
   from 2001:db8:aaaa::1      ====> packet filter applies policy
   to 2001:db8:bbbb::1 on LAN       NAT redirects to 2001:db8:aaaa::
                                                |
                                                V
                                    TCP negotiates thru NAT between
                                    router at 2001:db8:aaaa:: and
                                    client at 2001:db8:aaaa::1
				   Proxy accepts TCP from client
                                                |
                                                V
   Outbound TCP port 7070 SYN       NAT redirects from 2001:db8:aaaa::
   from 2001:db8:aaaa::1      <==== Proxy connects TCP to server from
   to 2001:db8:bbbb::1 on WAN       router at 2001:db8:aaaa:: thru NAT
                                                |
                                                V
                                    Proxy intercepts SETUP method
                                    Adds state for RTP/RTCP flows
				   found in Transport: header
                                    [etcetera]

Can I do this without NAT?  I don't see how.  I'd really like to know  
how, which is why I'm spending so much of Apple's time trying to find  
out if the IETF community has solved this problem already in some way  
I don't yet understand.

Somehow, I've got to get my FTP and RTSP proxies to be a "man in the  
middle" for IPv6 the same way they do today for IPv4, but accepting  
TCP connections from clients and making TCP connections to servers,  
parsing the control streams to learn about data transport flows and  
managing their pinholes in the stateful packet filter.

That seems pretty easy to do by extending IPv6 NAT, and truthfully,  
that's what management here seems to think is the best path forward  
at this point.

> You could surely redirect by encapsulation, and possibly by using a  
> host route.

How?  The proxies bind to a local interface address to receive TCP  
connections intended for other destinations.   They insert themselves  
into the flow explicitly to maintain the appearance of transparency  
at the router.  I don't see any way to do that without deploying NAT.

---

From: james woodyatt <[email-masked]>
Date: Tue, 17 Apr 2007 12:33:12 -0700

On Apr 17, 2007, at 02:09, [email-masked] wrote:
>> support > the stateful packet filter. (I'd say it's the market  
>> that seems
>> unconvinced-- despite the laudable efforts of the authors of the  
>> NAP draft-- that IPv6 is sufficient for their needs without  
>> general purpose
>> Therefore... the easiest way forward for me is the shortest path:  
>> by extending my general purpose IPv4 NAT to support IPv6. It  
>> saddens me to have to do it, but there it is.
>
> If I understand what you are trying to do, you want to take the end- 
> to-end connectivity of IPv6 and break it in order to support  
> applications that are running on multiple machines (thus IP  
> addresses) just like the work around that was developed in IPv4  
> rather than having a load sharing or other device in front of the  
> servers that would balance them on the back end?

No.  I'm just trying to get active mode FTP clients and Quicktime/ 
RealPlayer streaming clients, which use RTCP/RTP transports, to  
communicate properly from the local network with servers on the IPv6  
WAN the way they do today with servers on the IPv4 WAN.  Maybe next  
month, I'll try to get more esoteric applications to work.

The end-to-end connectivity of IPv6 IS ALREADY BROKEN-- by the  
insistence that stateful packet filters block inbound flow  
initiations in factory default configurations of residential IPv6  
gateways.  This is *exactly* how the end-to-end connectivity of IPv4  
got broken.  We are all now merrily marching off to do it again to  
IPv6, and I'M NOT IN A POSITION TO STOP IT.  I could point fingers at  
people who are, or at least might have been a couple years ago, but  
that wouldn't be terribly helpful, now would it?  They know who they  
are.

On a closely related note, I'd like to believe that the collective  
voice of the IETF could rise up and defend IPv6 from the predations  
on its end-to-end connectivity represented by these stateful packet  
filters, but as far as I can tell, the IETF is busy cheering it on,  
c.f. draft-ietf-nap.  It's been several weeks since I first started  
raising this issue here, and I've not seen any sign whatsoever that  
V6OPS or the wider IETF is at all concerned about the loss of end-to- 
end connectivity in IPv6 caused by these filters.

It's easy to conclude that the end-to-end connectivity of IPv6 is not  
expected to be any better than it is with IPv4/NAT, and that IETF  
thinks this is perfectly reasonable.  Be assured, Apple engineering  
management has NOTED WELL how this discussion has unfolded, and is  
making plans accordingly.

---

From: Gert Doering <[email-masked]>
Date: Tue, 17 Apr 2007 22:38:06 +0200

Hi,

> end connectivity in IPv6 caused by these filters.

Well, I'm certainly not "v6ops or the wider IETF", I'm just an operator,
and I *have* voiced my concerns (in the form of a mail full of "I don't
really understand this discussion" questions).

Given that we seem to be here because "folks that decide" insist on 
having IPv6 stateful packet filters on-by-default on zero-conf devices,
we *need* to have some sort of "please open this inbound port for me"
communication mechanism.

> making plans accordingly.

I don't think this discussion can be used to conclude how "the IETF 
thinks" (but unfortunately, the IETF decision process is a bit on the
slow side).

Gert Doering
        -- NetMaster

---

From: james woodyatt <[email-masked]>
Date: Tue, 17 Apr 2007 20:33:13 -0700

On Apr 17, 2007, at 13:38, Gert Doering wrote:
> thinks" (but unfortunately, the IETF decision process is a bit on  
> the slow side).

Are there any other ways to determine what the IETF thinks?  Are  
working group discussions *not* the formal record of IETF deliberations?

By the way, this discussion has forked in the BEHAVE working group,  
where we are talking about precisely what to do about the passive  
endpoint problem.  Apparently, there is still some unresolved  
controversy about the proper behavior of asymmetric packet filters.   
It remains non-controversial that asymmetric packet filters should  
and will be ubiquitous in the IPv6 internet.  The controversy is only  
about whether they should use endpoint-independent filtering or  
endpoint-dependent filtering.  In either case, we will still need  
ALG's and/or some kind of functional equivalent to UPnP IGD and NAT- 
PMP in IPv4/NAT.  Solutions of the STUN/ICE kind are of insufficient  
utility because they depend on 3rd-party nodes in the network to  
facilitate the signaling that allows endpoints to exploit the side  
effects in asymmetric packet filters.

My purpose in this thread of the V6OPS working group is constrained  
to raising the awareness within IETF about it potentially encouraging  
the development of NAT for IPv6 to solve some of the problems with  
the need to enhance stateful packet filters with application layer  
gateways.  That seems like something the V6OPS working group might  
want to be tracking.  So far, I haven't seen any compelling arguments  
not to move forward with my plans, but I've still got some time to  
argue it out.

---

From: [email-masked]
Date: Wed, 18 Apr 2007 01:51:33 -0600

James, 

As you are looking to get this to work in a wireless mode have you looked 
over the draft-madanapalli-ipv6-periodic-rtr-advts document by the 
Networking Group? 

In addition to all the reasons why the authors of the Local Address 
Protection (formerly NAP) document this document explains some of the 
considerations that using NAT deceases battery life due to the regular need 
to check if the end node is still attached. These 30 second keep alives tend 
to reduce battery life up to 50%. 

To Paraphrase Alex Lightman:
When a mobile device has a private address, it receives an endless series of 
"keep alives". The carrier's NAT wants to assign the private number to 
another device, and so it keeps "checking the roast", but this burns up the 
battery. With an IPv6 address once the connection is made there is no need 
to keep "checking the roast" every few seconds. -
http://www.usipv6.com/6sense/2004/oct/october03.htm 

This seems worth keeping NAT out of IPv6 for mobile devices alone in 
addition to the reasons that were in our document. 

Eric

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Apr 2007 10:20:08 +0200

I am confused.

If the issue is stateful packet filters the solution is
to be able to configure them off for specified hosts. I can't
see why transport proxies are needed (as far as you describe them,
they exist *because* the IPv4 box is a NAT, not because it
contains stateful filters).

Why is this different from the need today to configure
port forwarding in a NAT?

There is certainly some follow up needed to draft-ietf-v6ops-nap,
to define what a SOHO IPv6 gateway should do by default and what
it should be configurable to do.

     Brian

On 2007-04-17 20:58, james woodyatt wrote:
> The immediate visibility of the problem is as an implementation concern 
> for the existing AirPort Extreme base station product, where the NAT 
> would be used only within the router itself, though I can imagine more 
> complicated application level gateway deployments that might require the 
> NAT to redirect from the filtering router to a proxy running on another 
> middlebox.
> 
> + We have an IPv4 packet filter with an integrated NAT.  The way the FTP 
> and RTSP gateways are implemented is that NAT redirection rules are 
> applied to the local interface to translate all outbound flows from FTP 
> control streams and RTSP streams into a locally running proxy service.
> 
> the IPv4 case, it translates IP addresses in the FTP control stream.  It 
> also inserts and removes state records for the FTP data streams it 
> learns about in the process.  The equivalent things happens in the RTSP 
> proxy.
> 
> anything, but they do still need to insert and remove state records for 
> the associated TCP and UDP flows they learn about from parsing the FTP 
> and RTSP streams.
> 
> Here's a crude attempt at a picture of what's going on inside the router 
> for the RTSP case, which is what allows Quicktime Streaming and 
> RealPlayer streaming to use RTCP/RTP transports:
> 
> out if the IETF community has solved this problem already in some way I 
> don't yet understand.
> 
> middle" for IPv6 the same way they do today for IPv4, but accepting TCP 
> connections from clients and making TCP connections to servers, parsing 
> the control streams to learn about data transport flows and managing 
> their pinholes in the stateful packet filter.
> 
> that's what management here seems to think is the best path forward at 
> this point.
> 
> into the flow explicitly to maintain the appearance of transparency at 
> the router.  I don't see any way to do that without deploying NAT.
> 
> 
> --

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 18 Apr 2007 10:03:42 -0400

> contains stateful filters).

I think I agree.  It looks like James is saying that *in his code*,
implementing IPv6-NAT is the easiest way to re-use existing upper-layer
packet inspection code in order to poke holes in the firewall.  I don't
think that this in any way applies to implementations in general.

I believe he's only said that this seems like the path of least
resistance in his code, but I don't think he's said that it would be
impossible to re-use his packet inspection code through some other means
without implementing IPv6-NAT, but I may have missed something.

I think this is being blown out of proportion and confusing one
implementation's decisions with the protocol requirements in general.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 18 Apr 2007 17:18:32 +0300

Le mercredi 18 avril 2007 10:51, [email-masked] a écrit :
> When a mobile device has a private address, it receives an endless
> series of "keep alives". The carrier's NAT wants to assign the
> private number to another device, and so it keeps "checking the
> roast", but this burns up the battery. With an IPv6 address once the
> connection is made there is no need to keep "checking the roast"
> every few seconds. -

It's as much of a problem with stateful firewalls, as you will need to 
send refresh packets for hole punching every now and then (and sending  
is probably worse than receiving to the battery).

Unless you have a signaling protocol that allow negociating very long 
refresh intervals.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: james woodyatt <[email-masked]>
Date: Wed, 18 Apr 2007 11:00:52 -0700

On Apr 18, 2007, at 00:51, [email-masked] wrote:
> roast", but this burns up the battery. With an IPv6 address once  
> the connection is made there is no need to keep "checking the  
> roast" every few seconds. -
> This seems worth keeping NAT out of IPv6 for mobile devices alone  
> in addition to the reasons that were in our document.

Won't the keep-alives need to be sent from the mobile device to keep  
the *filter* state from timing out whether there is NAT in the loop  
or not?  It seems to me this is just a fact of life that mobile  
wireless devices are going to have to endure, simply as a result of  
our insistence that gateways implement asymmetric stateful packet  
filters in factory default configurations.

---

From: james woodyatt <[email-masked]>
Date: Wed, 18 Apr 2007 11:25:04 -0700

>> contains stateful filters).

The transport proxies don't exist just because the IPv4 box is a  
NAT.  They would need to be there even if the box implemented IPv4  
stateful packet inspection/filtering without NAT.  Let me outline the  
logical flow:

   1) SPI -> ALG
   2) ALG -> transport proxies
   3) transport proxies -> NAT

   therefore

   4) SPI -> NAT

We will never need NAT for translating between global and private  
IPv6 address realms.  That's not at issue.  However, we *do* need NAT  
for transparently redirecting IPv6 flows into transport proxies to  
implement application layer gateways to permit stateful packet  
inspection filters to keep from breaking Internet applications.

> think that this in any way applies to implementations in general.

This is true to a point.  Unfortunately, there isn't anything  
particularly special about my implementation.  If you looked at the  
source code, you'd see it's very similar to other implementations  
widely deployed on the Internet today.

It's also true that some applications, e.g. RealPlayer comes to mind,  
are just not easily handled without using transport-layer transparent  
proxies.  I've implemented ALG's for that using both methods, i.e.  
network-layer packet inspection and transport-layer proxy, and 1) the  
difference in engineering costs to maintain them is stark, plus 2)  
the transport-layer proxy is more functional because it doesn't break  
when headers are split across multiple TCP segments, as sometimes  
happens.

> without implementing IPv6-NAT, but I may have missed something.

Not impossible, but many will find it prohibitively expensive and  
difficult.

What I hope the V6OPS group will take away from this discussion is  
the awareness that, if my engineering management is thinking that  
implementing IPv6-NAT is worth doing to make application layer  
gateways function properly, then others may too.  If there is a goal  
to make IPv6-NAT an unnecessary tool and a waste of resources to  
develop, then that goal is *not* being met.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 18 Apr 2007 22:05:00 +0300

> stateful packet inspection/filtering without NAT.  Let me outline the

You can do connection tracking with SPI, without ALG. You only need an 
ALG *if/because* you have a NAT because the SDP content will then be 
broken, not the other way around.

> inspection filters to keep from breaking Internet applications.

ALG do keep breaking Internet applications.

By putting more ALGs, you will only incite software vendors and 
protocols designers to use TLS for just about everything (SIP outbound 
being one current example, STUN and Teredo XOR mapped addresses another 
one).

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: [email-masked]
Date: Wed, 18 Apr 2007 13:05:52 -0600

james woodyatt writes: 

>> series of "keep alives". The carrier's NAT wants to assign the  private 
>> number to another device, and so it keeps "checking the  roast", but this 
>> burns up the battery. With an IPv6 address once  the connection is made 
>> there is no need to keep "checking the  roast" every few seconds. -
> Won't the keep-alives need to be sent from the mobile device to keep  the 
> *filter* state from timing out whether there is NAT in the loop  or not?  
> It seems to me this is just a fact of life that mobile  wireless devices 
> are going to have to endure, simply as a result of  our insistence that 
> gateways implement asymmetric stateful packet  filters in factory default 
> configurations.

James, 

It is my understanding that IPv6 based mobile devices will need to do keep 
alives at least half as many times as IPv4 NAT based devices. That said, I 
am not sure what the affect that stateful packet filters will have on the 
flow and if they will be implemented at the device or in the network 
upstream of the mobile device to save radio bandwidth. 

Maybe one of the guys from Nokia (who did the testing of battery life) can 
answer this.

---

From: james woodyatt <[email-masked]>
Date: Wed, 18 Apr 2007 12:36:44 -0700

> broken, not the other way around.

I'm not limiting my discussion to just SIP.  I'm speaking of ALG's in  
the abstract sense.  If you have SPI, then you will need ALG's for  
some subset of all possible applications.  If you have ALG's then  
some subset of them will only be feasible with transport-layer  
proxies.  If you have transport layer proxies then you will need IPv6  
NAT to redirect flows into them.

However, I suppose I should admit that the unified IPv6 global  
addressing scope means that many (if not all) ALG's will be  
unnecessary once applications are all upgraded to traverse stateful  
packet filters using STUN/ICE-like mechanisms.  In the BEHAVE group,  
the evolving discussion is convincing me that IETF expects future  
IPv6 applications to depend on the deployment of a global rendezvous  
infrastructure of some yet-to-be-specified design.

The fact that this global rendezvous infrastructure is vapor seems  
not to faze anyone?

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 18 Apr 2007 23:07:28 +0300

> infrastructure of some yet-to-be-specified design.

An applications that does not support hole punching à la STUN/ICE may 
need an ALG to traverse a stateful firewall. But so long as you have 
enough addresses for every hosts, there is NO NEED to NAT or otherwise 
modify the packets at all; you only need to keep automagically open 
pinholes for connections that are "related" (borrowing Linux-NetFilter 
naming hree) to some existing connections... e.g. open a hole for an 
FTP data connection if you see the need according to the FTP control 
session, or for the RTP and RTCP flows of an RTSP media.

I don't see the need for a NAT there.

IMHO, it would of course be much better for the unmanaged networks 
scenarios to not have stateful firewalls by default at all. In fact, 
restored connectivity is the only incentive for "end-user" ISPs to 
deploy IPv6 at the moment, as far as I can tell. Why would they invest 
if it brings just about nothing? In that sense, it seems to me that 
Apple Airport decision and v6ops NAP is on a collision course with 
ISPs. But I should rather let ISPs speak for themselves.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Gert Doering <[email-masked]>
Date: Thu, 19 Apr 2007 00:35:32 +0200

Hi,

> I don't see the need for a NAT there.

That's an implementation detail.

You can either do it at the packet inspection level ("netfilter 'related'
connections"), or you can do it using a "proxy program" approach - like
the way you can use Squid to do transparent web proxy/caching even 
without client users knowing.

If you use the second approach, you need some sort of NAT (local to
the machine) to make the packets that come in, destined for some other
host, to end up in your local userland socket.

> ISPs. But I should rather let ISPs speak for themselves.

I share the sentiment that "unmanaged networks and stateful firewalls"
is a problematic scenario, but it seems that this is what we *have*
(due to not-so-well informed decision processes).

So if that is going to stay, we need a communication "process" between
application and stateful firewall.

Much better would be a public statement "for the unmanaged case, use
on-host distributed firewalls, for the managed case, use whatever fits
the bill".  (But even then you end up in the case of an application
requiring a pinhole and the firewall not supporting this specific
protocol)

Worse, should ubiquitous (sp?) IPSEC ever happen, network layer firewalls 
have no way to decide on "this is a good or bad packet", so the firewalls
really need to be on the host.

(Speaking from an ISP POV: the end-user ISPs will deploy IPv6 if and only
if customers are asking for it, or they can sell a product that will
only work with IPv6, like 'some sort of voip or IPTV product'.  Or if
they can't get IPv4 addresses for new subscribers anymore.  If there is 
no extra money, or compelling force, end-user ISPs won't do IPv6).

Gert Doering
        -- NetMaster

---

From: james woodyatt <[email-masked]>
Date: Wed, 18 Apr 2007 15:45:40 -0700

On Apr 18, 2007, at 15:35, Gert Doering wrote:
>
> I share the sentiment that "unmanaged networks and stateful  
> firewalls" is a problematic scenario, but it seems that this is  
> what we *have* (due to not-so-well informed decision processes).

I don't think I would agree with this characterization of how we have  
arrived at the present situation.  As the authors of draft-ietf-nap  
have noted, the situation is the result of the most informed  
community of Internet experts in the world, the IETF, recognizing its  
own technical consensus about the need for stateful firewalls in  
residential gateways.

If anything, I would have to accept my share of personal  
responsibility for my involvement in allowing Apple to ship the first  
release of firmware for the AirPort Extreme base station *without*  
the stateful firewall protecting its unmanaged local network.  This  
was clearly an uninformed decision, and Apple was roundly disparaged  
in the technical press for it-- presumably by well-informed critics.   
This mistake might have been avoided if I had seen draft-ietf-nap  
sooner than I did.

---

From: Gert Doering <[email-masked]>
Date: Thu, 19 Apr 2007 11:29:45 +0200

Hi,

> own technical consensus about the need for stateful firewalls in  

Well, just to clarify this.  I didn't mean to imply that *you* have been
"not so well-informed" - but the whole process went wrong.

Please do also note that a single IETF *draft* is not necessary "the IETF
consensus", but "a single working group in the IETF, and most likely
just a few individuals in that working group that found time to read the
draft and comment on it" - and it's very well possible that these 
individuals have overlooked some of the implications that this might
bring with it.

Personally, I am guilty of not having read the NAP draft in detail - the
general direction "we don't need NAT with IPv6" was something I agreed
to, but the consequence "if we require stateful firewalls on zero-conf
networks, we will have lots of interesting new problems" was something 
at least I didn't think of.

[..]
> This mistake might have been avoided if I had seen draft-ietf-nap  

I can't agree with this assessment.  I think that people who complain 
about "this device has no (automatic, zero-conf and default-on) firewall!!!" 
when there is no mechanism yet to distribute policy information between 
hosts behind the firewall and the firewall itself are doing IPv6 a 
disservice, and are not very well-informed.

(I hope that Apple AirPort Extreme base station has a configuration
knob to turn *off* the IPv6 firewall - otherwise I won't buy one. 
I have a firewall in my network, which is configured to let in those
packets I want to see there, and a zero-conf-everything-disallowed
firewall would break stuff)

Gert Doering
        -- NetMaster

---

From: "Gunter Van de Velde \(gvandeve\)" <[email-masked]>
Date: Thu, 19 Apr 2007 15:25:44 +0200

I am slightly confused here. The NAP document is a document to 
describe that what you have with NAT can be done natively with 
IPv6 (without the header modification option) and this is seen 
in both the abstract and the introduction.

<>
Abstract

   Although there are many perceived benefits to Network Address
   Translation (NAT), its primary benefit of "amplifying" available
   address space is not needed in IPv6.  In addition to NAT's many
   serious disadvantages, there is a perception that other benefits
   exist, such as a variety of management and security attributes that
   could be useful for an Internet Protocol site.  IPv6 was designed
   with the intention of making NAT unnecessary, and this document shows
   how Local Network Protection (LNP) using IPv6 can provide the same or
   more benefits without the need for address translation. 
<>

And there is also in the introduction

<>
   This document describes the uses of a NAT device in an IPv4
   environment that are regularly cited as 'solutions' for perceived
   problems.  It then shows how the goals of the network manager can be
   met in an IPv6 network without using the header modification feature
   of NAT.  It should be noted that this document is 'informational', as
   it discusses approaches that will work to accomplish the goals of the
   network manager.  It is specifically not a BCP that is recommending
   any one approach, or a manual on how to configure a network.
<>

To come back to the question of simple firewall:

1) if a CPE is running NAT, then it tends to have statefull behaviour
for filtering aspects

thus
2) If this is what you want, then just implement the statefull behaviour
with IPv6.

Will the end result will be same wrt statefull filtering?

I don't understand the problem discussed and maybe there is need 
for a problem statement draft to clear out the confusion.

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gert Doering
Sent: Thursday, April 19, 2007 2:30 AM
To: james woodyatt
Cc: IETF V6OPS WG
Subject: Re: The argument for writing a general purpose NAT for IPv6

Hi,

On Wed, Apr 18, 2007 at 03:45:40PM -0700, james woodyatt wrote:
> >firewalls" is a problematic scenario, but it seems that this is what 
> >we *have* (due to not-so-well informed decision processes).
> 
> have noted, the situation is the result of the most informed community

> of Internet experts in the world, the IETF, recognizing its own 
> technical consensus about the need for stateful firewalls in 
> residential gateways.

Please do also note that a single IETF *draft* is not necessary "the
IETF consensus", but "a single working group in the IETF, and most
likely just a few individuals in that working group that found time to
read the draft and comment on it" - and it's very well possible that
these individuals have overlooked some of the implications that this
might bring with it.

[..]
> release of firmware for the AirPort Extreme base station *without* the

> stateful firewall protecting its unmanaged local network.  This was 
> clearly an uninformed decision, and Apple was roundly disparaged

about "this device has no (automatic, zero-conf and default-on)
firewall!!!" 

(I hope that Apple AirPort Extreme base station has a configuration knob
to turn *off* the IPv6 firewall - otherwise I won't buy one. 
I have a firewall in my network, which is configured to let in those
packets I want to see there, and a zero-conf-everything-disallowed
firewall would break stuff)

Gert Doering
        -- NetMaster

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 19 Apr 2007 17:22:37 +0300

> in both the abstract and the introduction.

Problem is: many people understand this as a statement from IETF that 
CPE should have stateful filtering, and have it enabled by default.

So now, people are implementing this in their IPv6-capable CPEs. And 
then, we realize this re-introduces the connectivity limitations of 
IPv4+NAT into IPv6. Arguably, this destroys much of the advantage of 
IPv6 over IPv4 in the unmanaged network scenario.

So... yes we certainly need another document to clarify things, and to 
provide an answer to connectivity issues within IPv6 context (whether 
that's no firewall, firewall signaling, hole punching, or whatever).

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 19 Apr 2007 16:39:51 +0200

On 17-apr-2007, at 21:33, james woodyatt wrote:

> communicate properly from the local network with servers on the  
> IPv6 WAN the way they do today with servers on the IPv4 WAN.  Maybe  
> next month, I'll try to get more esoteric applications to work.

> gateways.  This is *exactly* how the end-to-end connectivity of  
> IPv4 got broken.  We are all now merrily marching off to do it  
> again to IPv6, and I'M NOT IN A POSITION TO STOP IT.

I feel slightly responsible here after writing this:

http://arstechnica.com/journals/apple.ars/2007/2/14/7063

The problem is that people are now getting IPv6 connectivity without  
realizing it, and having everything open over v6 despite filtering  
efforts (yes, NAT isn't a firewall, but these people don't really  
know what either of these words mean anyway) is can only end badly.

However, let me propose a different direction for solving this:  
rather than waiting until a port number is selected, put into a  
control stream, then intercept that control stream, recover the port  
number and open up the firewall, why not simply set aside a range of  
port numbers for these types of purposes and let those through the  
firewall?

With IPv4 this wouldn't work because there has to be a mapping  
between an private and a public address, but with IPv6 that's not  
necessary.

I can see how someone may be uncomfortable with this because it means  
it's still possible for packets to come in from the outside to hosts  
on the inside, but as long as no services are present on the ports in  
question, that's not really an issue, except for possible IP layer  
exploits, but I'm pretty sure that's a thing of the '90s.

Iljitsch van Beijnum

---

From: james woodyatt <[email-masked]>
Date: Thu, 19 Apr 2007 10:33:50 -0700

On Apr 19, 2007, at 02:29, Gert Doering wrote:
>
> it's very well possible that these individuals have overlooked some  
> of the implications that this might
> bring with it.

I brought the issue to the attention of the authors of draft-ietf- 
v6ops-nap quite some time ago, and they assured the V6OPS group that  
this was not an oversight on their part, and that the consensus  
behind the recommendation is widely shared throughout the Internet  
engineering community.  They noted that the draft has been the  
subject of intensive discussions for several years now, working group  
last call, IESG review, and is now in the RFC Editor Queue awaiting  
the start of its AUTH48 event.

I was initially offering my remarks in the context of what I  
mistakenly thought was be an editorial matter.  If there is any  
technical controversy, it is *not* coming from me and never did.  As  
I've explained elsewhere, I'm not in any position to mount a  
technical case for preserving end-to-end IPv6 connectivity,  
particularly considering the strength of the authorities lined up on  
the other side of that argument.

---

From: james woodyatt <[email-masked]>
Date: Thu, 19 Apr 2007 10:44:20 -0700

On Apr 19, 2007, at 07:39, Iljitsch van Beijnum wrote:
> control stream, then intercept that control stream, recover the  
> port number and open up the firewall, why not simply set aside a  
> range of port numbers for these types of purposes and let those  
> through the firewall?
>

An RTSP server may put any IPv6 address in the source attribute of a  
Transport header, so these ports would have to be open at all times  
to the whole Internet.  An RTSP server may *also* put any pair of UDP  
port numbers (starting on an even number) in the client_port  
attribute of a Transport header, so the ports that would have to be  
opened to the whole Internet include a very wide range, potentially  
*all* of them.

You're telling me that the way to solve the problem is allow all UDP  
packets through the filter.  And that's just to make RealPlayer and  
Quicktime work properly.  What about IPsec (without the ESP  
encapsulated in UDP) using ISAKMP?  Should I just pass all ESP  
packets through too?  I don't think this proposal will be met with  
much enthusiasm by the security experts at Apple who are already  
smarting over the embarrassing discovery noted earlier.

I'd like to direct members of the group interested in continuing this  
discussion about IPv6 filtering behaviors to the ongoing discussion  
in the BEHAVE working group.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 19 Apr 2007 21:47:03 +0200

> An RTSP server may put any IPv6 address in the source attribute of  
> a Transport header, so these ports would have to be open at all  
> times to the whole Internet.

Right. So the question is, what are we trying to accomplish? If the  
host and the firewall device are working together, it doesn't much  
matter which of the two rejects unwanted packets. Since the host  
_does_ know what the RTSP server is up to, it can easily reject  
unwanted packets.

In my opinion, what you need the firewall device for is to make sure  
that you can run services on the internal network without exposing  
those services to the rest of the world. So as long as the firewall  
device rejects all packets that are addressed to ports where services  
may run, that's accomplished.

> An RTSP server may *also* put any pair of UDP port numbers  
> (starting on an even number) in the client_port attribute of a  
> Transport header, so the ports that would have to be opened to the  
> whole Internet include a very wide range, potentially *all* of them.

That seems strange. Wouldn't the client want to have some say in the  
port number it needs to open up? But if we can define a range of port  
numbers that will pass through firewalls, then obviously we can tell  
RTSP servers to use just these ports.

> You're telling me that the way to solve the problem is allow all  
> UDP packets through the filter.  And that's just to make RealPlayer  
> and Quicktime work properly.

That's one option. But if the RTSP protocol is so unusual in this  
respect that it can't live in an uPnP/NAT-PMP world, another option  
would be to change the protocol. Some mechanism to allow for the  
proxying that you need but without the address fakery makes sense,  
but that may be hard to accomplish.

> What about IPsec (without the ESP encapsulated in UDP) using ISAKMP?

What do you mean by that? Packets with ip6->nextheader == ESP? These  
are extremely simple firewall-wise: it's yes or it's no to all of  
them. Obviously a firewall device can't be an ISAKMP proxy, unknown  
entities in the middle messing with your packets is exactly what  
IPsec is supposed to protect you against.

> Should I just pass all ESP packets through too?

This is once again a question of whether the firewall and the host  
are working together, or working against each other. As a home user I  
would expect my firewall device to let everything that I initiate  
from the inside through by default, but in a corporate environment it  
may make sense to distrust hosts and be more restrictive.

ESP packets that don't match any state at the host will be rejected  
promptly without any adverse effects, so I don't see any reason to  
invest a lot of effort to make sure only ESP packets that match known  
state through the firewall device.

> I'd like to direct members of the group interested in continuing  
> this discussion about IPv6 filtering behaviors to the ongoing  
> discussion in the BEHAVE working group.

In my experience, mailing list hopping halfway through a discussion  
doesn't work too well. It would be good if the v6ops people could  
reach some conclusion (and hopefully, consensus) on these issues.

---

From: james woodyatt <[email-masked]>
Date: Thu, 19 Apr 2007 13:34:59 -0700

On Apr 19, 2007, at 12:47, Iljitsch van Beijnum wrote:
> That seems strange. Wouldn't the client want to have some say in  
> the port number it needs to open up?

I wasn't involved in the design of the RTSP protocol.

> But if we can define a range of port numbers that will pass through  
> firewalls, then obviously we can tell RTSP servers to use just  
> these ports.

There is no mechanism for RTSP servers to learn what ports they  
should be constrained to use.  Perhaps you mean we can tell RTSP  
server *administrators* to use just the ports we think are  
appropriate.  Alas, there is no mechanism for doing that, either.

>> UDP packets through the filter.  And that's just to make  
>> RealPlayer and Quicktime work properly.
>

I have neither the option of changing the RTSP protocol nor the means  
to force RTSP server administrators to use a limited range of client  
ports.  I have to make Quicktime and RealPlayer streaming, as they  
exist today, work properly and sooner rather than later.

> What do you mean by that? Packets with ip6->nextheader == ESP?

Yes.

> These are extremely simple firewall-wise: it's yes or it's no to  
> all of them. Obviously a firewall device can't be an ISAKMP proxy,  
> unknown entities in the middle messing with your packets is exactly  
> what IPsec is supposed to protect you against.

I think you might have missed an important part of the discussion.   
The problem is that outbound IKE initiations only punch holes for the  
well-known ISAKMP port.  They do not also punch holes for the  
associated inbound ESP packets without the assistance of an ISAKMP- 
aware gateway, i.e. basically an ALG for ISAKMP and IPsec flows.

> invest a lot of effort to make sure only ESP packets that match  
> known state through the firewall device.

Without an ISAKMP ALG in the gateway, ESP packets that *DO* match  
state at the endpoint node will be rejected by the firewall.

> reach some conclusion (and hopefully, consensus) on these issues.

I'm happy to continue the discussion separately or cross-posted to  
both working groups, as necessary.

If BEHAVE and V6OPS think relaxing the constraints on what inbound  
packets should be rejected by stateful packet filters in residential  
IPv6 gateway devices, then I'll take those recommendations to Apple's  
security team and see if they feel comfortable relaxing the behavior  
of future AirPort base station products.  At the moment, however, the  
recommendation is clear: no inbound packets should be passed unless  
they are associated with state matching flows initiated by local nodes.

I will agree: the more we can relax the constraints in question, the  
less need there will be to implement ALG's for IPv6 firewalls, and  
*therefore* the less demand there may be for the development of IPv6  
general purpose NAT, which is the topic of this particular thread of  
discussion.  That would certainly help.

I'm very pessimistic, however, that we can eliminate *all* of the  
impetus to implement ALG's for IPv6 firewalls without removing the  
constraint on inbound flows entirely, or by the implementation of an  
application listener discovery protocol for firewalls.  I'm more  
optimistic about the potential of the latter alternative than I am  
about the former.  To that end, I am drafting a proposal for solving  
this problem with a new ICMP sub-protocol.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 20 Apr 2007 00:52:12 +0200

Hopefully a change of the subject line will draw in more people, I  
think this is an important issue.

The issue being: what is the right thing to do in the long term, and  
what is the right thing to do in the short term. In the short term,  
changing protocols like RTSP isn't an option, but in the long term,  
it's not even an issue. What we have to avoid is starting something  
because it makes short in the short term that will hurt us in the  
long term.

In order to determine what our options are, we need to define the  
problem. Off the top of my head I can think of five applications or  
classes of applications that don't work with a simple stateful firewall:

1. Anything that listens for incoming sessions
2. Active FTP
3. SIP
4. RTSP
5. IPSEC

Possible solutions:

A. NAT-PMP like
B. ALG without host involvement
C. ALG with host participation
D. Open range of ports/protocols

I don't know very well how SIP or RTSP work, but I think the  
compatibility is as follows:

A: helps with 1, 3, 5; doesn't help with 2, 4
B: helps with 2, 3, 4; doesn't help with 1, 5
C: helps with 2, 3, 4, 5; doesn't help with 1
D: helps with 3, 5; doesn't help with 1, 2, 4

This means we need at least A, and either C or both B and D.

Alternatively, we could collectively decide that this is too  
problematic and too harmful to the e2e principle, so we shouldn't  
have stateful firewalls in the common case after all. However, in  
that case we need to come up with a way to provide services on a  
local network in such a way that those services aren't exposed to the  
rest of the world. That would mean providing these services over non- 
routable address space, such as link-local for unmanaged  
installations and unique site local for larger installations. Apple  
would probably be in a good position to do this because Mac OS  
doesn't expose any services by default, but I think this is (still)  
different for Windows.

This would also mean that services aren't just enabled or disabled,  
but they are enabled for global use, enabled for local use or disabled.

Back to our earlier exchange...

On 19-apr-2007, at 22:34, james woodyatt wrote:

>> But if we can define a range of port numbers that will pass  
>> through firewalls, then obviously we can tell RTSP servers to use  
>> just these ports.

> appropriate.  Alas, there is no mechanism for doing that, either.

This is where the short/long term issue comes up: the IETF could  
easily update the RTSP specs to do this, but it would take years for  
that to take effect, so that's of no short term value.

>> unknown entities in the middle messing with your packets is  
>> exactly what IPsec is supposed to protect you against.

> The problem is that outbound IKE initiations only punch holes for  
> the well-known ISAKMP port.  They do not also punch holes for the  

All of this comes with the territory, you simply can't have a  
middlebox meddle with IPsec. However, I don't see any security issues  
with allowing ALL protocol ESP packets through firewalls, because  
IPsec has a very good handle on which packets it wants to see and  
thus, which packets it doesn't want to see. No need to have a  
firewall "protect" hosts. Unfortunately, people have been living  
behind firewalls for so long that receiving packets from the big  
scary internet simply feels "wrong".

>> In my experience, mailing list hopping halfway through a  
>> discussion doesn't work too well. It would be good if the v6ops  
>> people could reach some conclusion (and hopefully, consensus) on  
>> these issues.

> both working groups, as necessary.

Ok. I'll subscribe to BEHAVE tomorrow.

> packets should be rejected by stateful packet filters in  
> residential IPv6 gateway devices, then I'll take those  
> recommendations to Apple's security team and see if they feel  
> comfortable relaxing the behavior of future AirPort base station  
> products.  At the moment, however, the recommendation is clear: no  
> inbound packets should be passed unless they are associated with  
> state matching flows initiated by local nodes.

Maybe it would be useful to ask the chairs for a consensus call.  
However, this generally only happens when there is a draft.

In my opinion, a firewall shouldn't have to reject ALL packets for  
which there is no state, but for consumer stuff, the protection  
against possible malicious incoming traffic should be the same for  
IPv6 as it is for IPv4+NAT.

> I will agree: the more we can relax the constraints in question,  
> the less need there will be to implement ALG's for IPv6 firewalls,  
> and *therefore* the less demand there may be for the development of  
> IPv6 general purpose NAT, which is the topic of this particular  
> thread of discussion.  That would certainly help.

> constraint on inbound flows entirely, or by the implementation of  
> an application listener discovery protocol for firewalls.  I'm more  
> about the former.  To that end, I am drafting a proposal for  
> solving this problem with a new ICMP sub-protocol.

Ok. It looks to me that you have a better view of the problem than  
(almost?) anyone else, so don't be afraid to take the position you  
think is right in both the long and short term, there is precedent  
for the IETF membership to be convinced by rational argument.  :-)

Iljitsch

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Apr 2007 11:00:42 +0200

On 2007-04-19 22:34, james woodyatt wrote:
...
> I'm happy to continue the discussion separately or cross-posted to both 
> working groups, as necessary.
> 
> IPv6 gateway devices, 

I've re-read the BEHAVE WG charter carefully, and I do not see
how it can be interpreted to make this discussion in-scope. Their
job is concerned with IPv4 NATs "with the goal of encouraging
eventual migration to IPv6". That doesn't mean they should be
recommending IPv6 CPE behaviour. Certainly, learnings from BEHAVE
can be useful to V6OPS. We're chartered to:

"Publish Informational or BCP RFCs that identify potential security
risks in the operation of shared IPv4/IPv6 networks, and document
operational practices to eliminate or mitigate those risks" and
"Publish Informational or BCP RFCs that identify and analyze
solutions for deploying IPv6 within common network environments..."

A document on CPE behaviour seems well in scope to me.

     Brian

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 20 Apr 2007 19:05:49 -0700

James,

I am trying to catch up here, and I don't think I understand the entire
picture. On one hand it looks like you are trying to insert a transparent
application proxy for the purpose of applying inbound policy without user
intervention. On another it looks like the only thing that you are trying to
proxy are the control protocols for a couple of specific use cases. In
either case, the problem statement looks more like a perceived need to
transparently redirect traffic off its normal routing path. For the example
given of the AirPort, it would be on-path by nature of its packaging so it
would have access to implement the policies before forwarding without the
need for any nat function. If I misunderstood please correct me.

It would be useful to understand a deployment scenario where the normal
state would be to intentionally divert traffic off the routing path to a
middle box. In particular, it would need to be clear why that would not be
done by encapsulating at the diversion point, or even simpler by forcing the
device to be on-path by aggregating the policy impacted nodes behind it on a
dedicated subnet. 

While I would encourage a draft on an ICMP protocol type for pinhole
management to raise the issues, I think one the reasons that the IETF has
trouble in the policy management space is the carve-off-a-tiny-piece
approach to everything, particularly without any intent to understand the
entire environment. Boiling the ocean is not productive, but defining a
systemic framework where the carved up pieces have some hope of relating to
each other (in some environments that might be called an architecture) is
what the IETF lacks. We have a pile of piece-parts that have been defined to
solve someone's hot-button, but nothing works together in a way that allows
a consistent policy to be implemented across a range of functional need. 

It sounds like you might have a use case that the -nap- draft does not deal
with. I was presented with another a couple of weeks ago. I do not want to
derail the effort to get the current doc out, because it needed to be in RFC
form about a year ago, but we should start on an update to it that covers
issues the current doc misses and how to resolve them without resorting to
nat.

Tony

> Behalf Of james woodyatt
> Sent: Thursday, April 19, 2007 1:35 PM
> To: IETF V6OPS WG

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 20 Apr 2007 19:33:09 -0700

I have been arguing for a long time now that we should be following the 3484
approach of 'smallest scope' by default (and I use the term scope with
intent). For example, there is no reason a printer should bind to anything
but a ULA prefix by default. I have heard complaints that the API does not
allow a service to register for a specific prefix range like ULA, but I have
not followed up to check that. While I understand that the app developer
does not want to worry about issues like scope, in the real world the
network is managed with scopes where policy is applied. Frequently the
addressing allocation aligns with those policy scopes, and can be
specifically forced to align when traffic needs to traverse a policy
enforcement point. 

One of the 'attitude' problems we have is that the people that want absolute
control through centrally managed knobs absolutely insist on B and reject C,
while people that write apps want to get deployed without having to wait for
the knob to be flipped globally, so they lean toward C and want A & B
abolished. I disagree that C does not help with 1, unless the app in the
case of 1 assumes there is no external filter. If 1 assumes there is a
filter but does not know where, it would seem a reasonable thing to do would
be to send an ICMP toward default that would be dropped by the pinhole
device at the border (one could debate about dropping it at the first device
since a layer of filters would need to propagate all the way up, but sending
it outside the policy realm makes no sense either).

Tony

> Behalf Of Iljitsch van Beijnum
> Sent: Thursday, April 19, 2007 3:52 PM
> To: james woodyatt
> Cc: IETF V6OPS WG
> Subject: Long term vs short term, was: Re: The argument for writing a
> general purpose NAT for IPv6
>

---

From: james woodyatt <[email-masked]>
Date: Fri, 20 Apr 2007 23:09:35 -0700

> need for any nat function. If I misunderstood please correct me.

I think you understand correctly.  I have both of these concerns.

On the one hand, there are certain applications that work over IPv4/ 
NAT today, which do not work over IPv6 in the default configuration  
of AirPort Extreme because the IPv6 SPI filter blocks inbound flows.   
These applications are handled properly in the IPv4/NAT case by  
application layer gateways (ALG).

On the other hand, I have the additional concern that we may never  
have a method of enabling the utility of new peer-to-peer application  
protocols (which nameless boffins are busy designing in their  
basement laboratories even as I write, and which scale better and  
work more efficiently if no relays need to be reachable in the middle  
of the network) *without* having to deploy ALG's everywhere in the  
Internet to support them.  (See below for more of my thoughts about  
that.)

If the future IPv6 Internet turns out to be one very much like the  
existing IPv4/NAT Internet, then I'm going to need to be able to  
deploy ALG's quickly and easily as new application protocols emerge.   
That gives me pause, because I already know how the need for ALG's  
gives rise to the need for NAT, and I'm really *NOT* excited about  
the idea of making a name for myself as the guy who brought NAT to IPv6.

> device to be on-path by aggregating the policy impacted nodes  

This is, I want to be careful to admit up front, a bit speculative.   
I may be out of my depth, and I'm hoping to be corrected if my  
understanding is wrong.  Here's one possible scenario that seems like  
the general case that has me concerned:

Consider the case of an application layer gateway for RTSP deployed  
in the firewall for a large population of endpoint nodes, i.e.  
numbering in the hundreds of thousands or even millions.  Grant that  
much of the RTP/RTCP traffic will be sent from media servers to  
clients on different paths than the reverse path from the RTSP  
servers.  Also grant that the fraction of endpoints using RTSP at any  
given time is small enough that the network can be provisioned with  
vastly fewer RTSP proxy nodes than stateful packet inspection  
firewall/routers.

In this scenario, diverting the RTSP stream from the firewall/router  
to the RTSP proxy transparently should probably be done by  
encapsulation rather than NAT, but let's be honest about how this  
will probably be developed in practice.  Once you've already got an  
RTSP proxy that works using NAT to redirect into a node-local  
interface address (just like your existing RTSP proxy already does  
with IPv4), the shortest path to getting your larger scale RTSP proxy  
system up and running is to reuse the mechanism you already have  
going.  Rather than encapsulate (which comes at the price of having  
to write the code that decapsulates at the other end of the tunnel  
and still lets TCP process the packets and present an octet stream to  
the proxy function), you just redirect with the NAT to an RTSP proxy  
node at a different address.  This is much easier.  That's how  
developers will do it.  I know that's how *I'M* currently planning to  
do it.

The idea of forcing the client devices to be on-path by aggregating  
the policy impacted nodes behind it on a dedicated subnet seems  
interesting.  What mechanism would you envision for doing that in the  
scenario outlined above?

I should also mention that my additional concern about applications  
that haven't yet been developed is part of what has me champing for  
an alternative to deploying ALG's everywhere.  It would be nice to  
have a long-term solution that didn't require constant upgrades to  
the middleware.

Self-organizing peer-to-peer applications seem to be generally  
incompatible with stateful packet filters that block all inbound  
flows by default.  I understand that many in the Internet engineering  
community don't consider this failure of end-to-end connectivity to  
be a great loss, but I think ordinary users will be unhappy with the  
final consequences in terms of application usability unless some  
ALG's are deployed to relax policy enforcement according to the  
specific needs of applications that can benefit from them.

Solutions like STUN/ICE/whathaveyou will always depend on the  
existence of two things that do not now exist: 1) a global peer- 
rendezvous service, and 2) a well-defined standard behavior for  
unmanaged IPv6 SPI firewalls.  I can see problems ahead trying to  
bring up solutions for each of those problems.  I don't see how we  
can escape the need for ALG's, and probably NAT as well, by relying  
only on SPI side effects.

I do think there are ways to avoid the need for ALG's, but they're  
going to require a lot of socialization-- and that's why you see me  
here trying to raise the visibility of these issues, partly by  
highlighting the costs of not doing anything, and also by pointing  
out practical avenues of development that could lead to practical  
solutions.

> a consistent policy to be implemented across a range of functional  

Perhaps, now would be a good time to reiterate that Apple designed  
the NAT-PMP protocol intending for it not to be easily extended into  
more than a transition mechanism for IPv4/NAT, only to be used until  
IPv6 deployment is ubiquitous.  It was a carve-off-a-tiny-piece  
approach because that was good architecture.

Everyone with whom I've talked about this at Apple believes that any  
proposal for a permanent addition to IPv6 for firewalls to discover  
application listeners will require an extremely thorough  
architectural review.  Ideally, we'd like to see the members of IAB  
join this discussion and offer whatever advice they think would help  
the working group build consensus around an architecturally sound  
solution to the class of problems under discussion here.

> issues the current doc misses and how to resolve them without  

In the case of draft-ietf-v6ops-nap, the thing I was initially trying  
to help avoid has now already happened in my immediate circles, i.e.  
product management has interpreted an INFO as a BCP.  It turned out,  
much to my embarrassment, that this really wasn't much of a mistake,  
and that nobody really cares about the distinction between a  
recommendation in an INFO and the same recommendation in a BCP.

I do still think there is a huge, glaring, problem before the V6OPS  
group, involving 1) unmanaged IPv6 networks subject to policy  
enforcement by 2) unmanaged stateful packet filtering firewalls.   
Whether that's really an open problem in the NAP draft, I'll leave to  
others to decide.

---

From: james woodyatt <[email-masked]>
Date: Fri, 20 Apr 2007 23:34:07 -0700

> specifically forced to align when traffic needs to traverse a policy

I thought we only had two unicast address scopes at this time: link- 
local scope and global scope.  (Okay, three if you count the  
deprecated site-local scope, but I don't.)  ULA's are global scope  
with limited reachability.  The API already permits applications to  
enumerate the addresses assigned to an interface.  They can bind to  
addresses explicitly rather than use wildcard binding.

Now is probably a good time for me to repeat my long-running refrain  
that OS implementations should permit system administrators to  
configure interfaces to ignore advertisements of global scope  
prefixes other than ULA prefixes.  I think this would help a lot over  
the short term.

Over the long term, I worry that something hideous will be required  
by the people who get paid lots of money to establish complicated  
functional requirements, and nobody but twelve-fingered post-human  
Martians will be able to manage which services are available in what  
regions of the Internet.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 26 Apr 2007 14:35:52 -0700

> Internet to support them.  (See below for more of my thoughts about

First thing we need to do is agree on terminology, not that I know the
answer, but it appears that your definition of an ALG & mine are different. 

To start with I would differentiate a signaling proxy from an ALG, where the
former may be required for rendezvous but does nothing with the content
stream, and the latter intercepts the content stream and in the case of nat
modifies it to deal with embedded addresses.

I would also differentiate ALG's based on if their primary purpose is to
establish an authentication checkpoint, or simply to align the content
stream with the nat mangling.

> the idea of making a name for myself as the guy who brought NAT to IPv6.

We should also come to some agreement about cause & effect. I don't believe
that the existence of an ALG creates a need for nat, but the existence of it
does allow for the 'opportunity'. SOCKS proxies existed long before nat, and
fill one aspect of a perceived need for a managed boundary. 

> vastly fewer RTSP proxy nodes than stateful packet inspection

I am willing to be open minded here, but that last point is hard to follow.
Very few organizations want an abundance of firewalls, so a vastly reduced
number of RTSP proxies sounds like a stretch. Typically the goal is to have
as few places where policy needs to be enforced as possible, just to make
sure it is being enforced consistently. 

> developers will do it.  I know that's how *I'M* currently planning to

This description screams out for use of the routing extension header. Off
the top of my head it is not clear to me that the firewall could insert one
without breaking something else, but if you don't want to write
decapsulation code at the receiver, the routing extension header would allow
diverting traffic to it while maintaining the original destination. Since
this is assumed to be 'transparent' the origin of the packet would not know
the diversion destination, but if it were defined that RTSP always carried
at least an empty routing header, then the firewall could move the original
destination there and forward to the proxy. The extension header parser in
the proxy would already know how to swap those back before forwarding on. 

> interesting.  What mechanism would you envision for doing that in the

I was not thinking about simple restriction to a subnet, rather that the
policy enforcement points would be limited in number and a collection of
subnets would naturally be aggregated behind those for routing. 

> have a long-term solution that didn't require constant upgrades to

That was the point of IPv6. 

> specific needs of applications that can benefit from them.

Again, we need to agree on terms here. A signaling proxy would be needed,
and a mechanism to dynamically manage the firewall would have to go with
that, but an ALG for the content stream doesn't sound like it is required.

> only on SPI side effects.

I agree that the IETF has not figured it out yet, but look at NTT's m2m-x
effort:
http://www.v6.ntt.net/02e_02m2mx.html
They have been thinking about this problem space for awhile now, and while
the signaling protocol can be debated, the need for coordination between the
signaling system and the firewalls is clear.

> out practical avenues of development that could lead to practical

The -nap doc was a start at the problem space. If we need to do additional
work to make your RTSP indirection work, then we should start another doc
that clearly states the problem and the trade-offs like
encapsulation/routing-extension/...

> approach because that was good architecture.

I was thinking more along the line that we have RSVP, COPS, NSIS, SIP, pick
your favorite signaling protocol related to policy, but none of them do more
than a small part of what a policy system needs.

> solution to the class of problems under discussion here.

Again, take a look at m2m-x. My comment to them was to use IPsec for auth
between the client and the firewall for pinhole management, and to
specifically insert a local SIP proxy for cases where the enterprise does
not want to allow the carrier to manage the firewall pinholes directly.

> recommendation in an INFO and the same recommendation in a BCP.

Lacking operational practice to clearly establish 'best', any information
will automatically fill the void.

> Whether that's really an open problem in the NAP draft, I'll leave to

You will have a very hard time with 'unmanaged' in most of the IETF, because
they are all technologists that understand how to manage, and most of them
build products for professional managers so they just can't get their minds
wrapped around the complexity that goes into masking the guts from the end
user. Never mind the logical disconnect between 'policy enforcement' as a
management function and the need to do that in an 'unmanaged' way.

Yes we need a policy signaling protocol suite that can deal with the real
trust boundaries in deployed networks, and that does not create a
significant burden on application deployment. ALG's (as in mangles the
content stream) are not the answer, because as you note they require
coordinated updates to deploy the yet to be dreamt up application. 

Tony

---

From: james woodyatt <[email-masked]>
Date: Thu, 26 Apr 2007 16:01:51 -0700

I'm splitting up my replies to this to keep two different conceptual  
threads of discussion separate.

> modifies it to deal with embedded addresses.

I don't see any need for an IPv6 filtering ALG to modify the  
application content, even in the presence of the NAT function I'm  
talking about.  There is no need for more than one IPv6 address realm.

> fill one aspect of a perceived need for a managed boundary.

I'm in complete agreement with this.

> sure it is being enforced consistently.

As I said, my RTSP example was meant to illustrate the general case  
that has me concerned.  It's possible that network operators know  
more about the practical considerations in this space than I do, and  
they can speak with authority about whether my concerns are overblown.

> the proxy would already know how to swap those back before  

I don't think the routing extension header is sufficient to solve the  
problem.  An application layer proxy has to be inserted into the  
transparently for the signaling of the filter to work properly.  I  
don't see how the routing extension header alone can be made to do that.

I'm prepared to admit that using the phrase "Network Address  
Translation" is a bit overloaded here, since we are just talking  
about diversion within the single, global IPv6 address realm, but the  
mechanism is basically the same.  The only difference is that it  
complicates the process of overwriting the IPv6 destination address  
by the need to also push a routing extension header.

I'll agree, though, that defining a way to use routing extension  
headers for this purpose would be a very good idea, since that's  
necessary to make path MTU discovery in the presence of transparent  
application proxies not resident with filtering firewalls work properly.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 26 Apr 2007 17:07:47 -0700

> talking about.  There is no need for more than one IPv6 address realm.

So essentially you are not really talking about an ALG or NAT at all. What
you have defined is a firewall rule that rather than just forward/drop adds
a state 'route via', then overwrites & restores the packet between the
firewall & the proxy. 

While that is a simple hack that would work within a single administrative
domain, I am not sure we want to standardize that as such. If it turns out
that the firewall can insert a routing header and push the real dst there
when overwriting with the proxy, then the proxy only has to do standard
extension header parsing.

> ...........

If the firewall inserts that extension, then pushes the original dst there,
that frees up the base header field for the proxy and results in 'standard'
extension header processing at the route-via point.

> by the need to also push a routing extension header.

Doing protocol design based on the ability to reuse existing code is not the
best practice. In any case the complexity is simply being moved around here.
If you take the nat approach, the proxy has to maintain state to restore the
packet. If you take the encapsulation approach, the proxy's stack will hand
up an intact packet ready to forward, rather than just the content so the
proxy parser would need to deal with that. If you take the extension header
approach the firewall has to move the original destination there before
overwriting the base with the address of the proxy. The lowest overhead
'stateless' of those is the last one, but I don't know if it breaks
anything, and I don't know if the proposed use would run into fragmentation
issues. As long as the end to end perceives that the packet sent was the
same as the packet received, if middle boxes mangle & restore it there is no
real problem. 

> application proxies not resident with filtering firewalls work properly.

I am buried right now, but in the next couple of months if you want to work
on an ID I would be happy to start one.

Tony

---

From: james woodyatt <[email-masked]>
Date: Thu, 26 Apr 2007 17:34:37 -0700

> extension header parsing.

At this point, I'm now persuaded that having a proxy remote from the  
filtering router will require the path between them to use some kind  
of encapsulation that looks like a routing extension header.  I'm  
still convinced that type code zero is the *wrong* one, but  
whatever... (at the diversion point, on the return path from the  
proxy, the source address needs to be rewritten to match the real  
destination, not the proxy, and normal routing extension header  
processing doesn't do that.)

I agree I'm guilty of a poor choice in words.  The IETF has defined a  
way to scribble on the destination addresses in IPv6 headers, and  
despite my long habit of calling that behavior by the name "network  
address translation," I should stop calling it that because, with  
IPv6, there is only one address realm involved.  Of course, I do need  
a way to scribble on source addresses as well as destination  
addresses...

---

From: james woodyatt <[email-masked]>
Date: Thu, 26 Apr 2007 18:34:10 -0700

everyone--

This is a continuation of a previous discussion under the subject  
"Re: The argument for writing a general purpose NAT for IPv6."

> That was the point of IPv6.

Perhaps.  I'm not sure it *remains* the point.

 From where I sit, it looks like we're all about restoring the  
Internet to a single, universal addressing realm.  There does remain  
some politicking on the side about address space resource  
allocation-- but, that seems aimed more at promoting transition in  
the minds of those who don't comprehend the addressing realm issue.   
(I'm doubtful that a political campaign will work, because I think  
the intended audience is at least smart enough to understand that  
economists know a lot about the practical matters of allocating  
scarce resources.)

My biggest worry about IPv6 is that transition may be slowed or even  
halted because of the basic problem that applications which work over  
IPv4/NAT today can't be made to work over IPv6 too, without still  
deploying ALG's everywhere and/or developing the moral equivalent of  
UPnP IGD and NAT-PMP (minus the UNSAF aspect).

> not want to allow the carrier to manage the firewall pinholes  

I've seen many proposals like this over the years.  I don't like them  
for three reasons:

   1) they're separate from the IETF standards that specify the  
requirements for
      IPv6 nodes and routers, and therefore likely to be available  
only on a
      limited subset of the Internet to a limited set of applications;

   2) they require application layer protocols to participate in  
network layer
      signaling; and...

   3) they don't permit peer-to-peer applications to work without  
relying on the
      availability of a third-party relay service.

In my humble opinion, this class of solutions represents a perversion  
of the Internet architecture-- though I recognize the IAB vigorously  
disagrees with this view.

I think applications shouldn't have to ask the network to see if they  
will be able to communicate before they begin communicating.  They  
should just attempt to communicate directly and offer users  
information to facilitate troubleshooting when communication fails  
for policy reasons.  These systems like m2m-x, ICE, STUN, etc. don't  
permit that-- instead, they require applications to communicate with  
a signaling rendezvous point to set up the network to allow  
communication to take place before they can initiate direct  
communications between user endpoints.  They're necessary evils where  
UNSAF methods are required for any communication to happen at all.   
They're an abomination in the absence of network address translation.

> management function and the need to do that in an 'unmanaged' way.

I'm referring to unmanaged networks in the sense defined in section  
5.2 of RFC 2462, particularly with regard to the "OtherConfigFlag"  
conceptual variable:

>>>       OtherConfigFlag  Copied from the O flag field (i.e., the  
>>> "other
>>>                        stateful configuration" flag) of the most
>>>                        recently received Router Advertisement  
>>> message.
>>>                        The flag indicates whether or not information
>>>                        other than addresses is to be obtained  
>>> using the
>>>                        stateful autoconfiguration mechanism. It  
>>> starts
>>>                        out in a FALSE state.
>>>
>>>                        In addition, when the value of the  
>>> ManagedFlag is
>>>                        TRUE, the value of OtherConfigFlag is  
>>> implicitely
>>>                        TRUE as well. It is not a valid  
>>> configuration for
>>>                        a host to use stateful address  
>>> autoconfiguration
>>>                        to request addresses only, without also  
>>> accepting
>>>                        other configuration
>>>                        information.

At least with DHCP6, you can imagine defining some options for  
telling nodes on "managed" networks, i.e. those with OtherConfigFlag  
set TRUE, about firewalls that have to be signaled to make  
applications work.  If there is no configuration service, however, I  
don't see how nodes can discover firewalls to signal without either  
1) doing something really noisy, or 2) adding a new router  
advertisement option to help control the problem.  New router  
advertisement option definitions, I'm told, are a tough sell in IETF.

The point you make about conveying to IETF regulars the complexity  
of, the importance of, and the foresight required in choosing  
appropriate defaults for consumer-grade network appliances is well  
taken.  It's clear to me now that the IETF has applied less thought  
to making the Internet easier for ordinary people to use than to  
making the operation of Internet services easier for technocrats to  
manage.  Hopefully, it's not too late to do something about that.

---

From: Remi Denis-Courmont <[email-masked]>
Date: Fri, 27 Apr 2007 8:46:37 +0200

> of encapsulation that looks like a routing extension header.

If you transmit "raw" IPv6 packets, yes. Of course, you're going to have

some big headaches with MTU if you encapsulate, however...

Unless you put some logic in the "filtering router" so that it returns

a Packet too big error if it sees a packet it wants to encapsulate but

cannot.

I am personnaly not convinced whether we really need a new RH type instead

of using plain proto-41 encapsulation, though. Another option, that might

not suffer from the MTU issue would be to use a different EtherType and

pass network-layer packets unmodified, but that's ugly and assumes a

shared medium between the filter and the proxy.

> I'm still convinced that type code zero is the *wrong* one, but

> processing doesn't do that.)

I agree. I would additionnaly rather not RHT0 be modified by middleboxes

in a way that is not specified.

--

Rémi Denis-Courmont

http://www.remlab.net/

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Fri, 27 Apr 2007 16:21:49 +0900 (JST)

> Perhaps.  I'm not sure it *remains* the point.

	IPv6 NAT?  you moron.  i'll remove Vincent Lubet from merge@kame.
	no new information will nor help will reach Steve.
	even if you give me 8core MacTower, i won't. i will never forgive you
	if you implement NAT in AirPortExtremeSuperDuper.
#	sorry for foul language.  too much stress and sleepless nights.
#	how come you can think i could go to bed?

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Fri, 27 Apr 2007 21:07:03 +0900 (JST)

do not even need to read the content:
	NAT has to go to hell with rthdr0.  do you know how many miles your
	IPv4 vehicle could go forward with 2cc of gas?

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Fri, 27 Apr 2007 21:27:06 +0900 (JST)

i'm responding to all article with this title, and going through emails
	backwards, so sorry if you got bored.

	NAT must be killed togherther with rthdr0, so they are in love.
	let them suicide, otherwise you have doomsday.

itojun

---

From: [email-masked]
Date: Fri, 27 Apr 2007 06:36:01 -0600

james woodyatt writes: 

> filtering router will require the path between them to use some kind  of 
> encapsulation that looks like a routing extension header.  I'm  still 
> convinced that type code zero is the *wrong* one, but  whatever... (at the 
> diversion point, on the return path from the  proxy, the source address 
> needs to be rewritten to match the real  destination, not the proxy, and 
> normal routing extension header  processing doesn't do that.) 
> 
> I agree I'm guilty of a poor choice in words.  The IETF has defined a  way 
> to scribble on the destination addresses in IPv6 headers, and  despite my 
> long habit of calling that behavior by the name "network  address 
> translation," I should stop calling it that because, with  IPv6, there is 
> only one address realm involved.  Of course, I do need  a way to scribble 
> on source addresses as well as destination  addresses... 
> 

I admit that I have not read the full document, but the following abstract 
seems to address some of your concerns by creating an overlay that would be 
used to address application level needs: 

 ----------Forwarded message ---------- 

Date: Fri, 27 Apr 2007 14:20:16 +0300
From: Jari Arkko <[email-masked]>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Internet Area <[email-masked]> 

Subject: [Int-area] FW: RFC 4843 on An IPv6 Prefix for Overlay Routable
Cryptographic Hash	Identifiers (ORCHID) 

> A new Request for Comments is now available in online RFC libraries. 
>
>         
>         RFC 4843 
>
>         Title:      An IPv6 Prefix for Overlay 
>                     Routable Cryptographic Hash Identifiers (ORCHID) 
>         Author:     P. Nikander, J. Laganier,
>                     F. Dupont
>         Status:     Experimental
>         Date:       April 2007
>         Mailbox:    [email-masked], 
>                     [email-masked], 
>                     [email-masked]
>         Pages:      14
>         Characters: 32483
>         Updates/Obsoletes/SeeAlso:   None 
>
>         I-D Tag:    draft-laganier-ipv6-khi-07.txt 
>
>         URL:        http://www.rfc-editor.org/rfc/rfc4843.txt 
>
> This document introduces Overlay Routable Cryptographic Hash
> Identifiers (ORCHID) as a new, experimental class of IPv6-address-
> like identifiers.  These identifiers are intended to be used as
> endpoint identifiers at applications and Application Programming
> Interfaces (API) and not as identifiers for network location at the
> IP layer, i.e., locators.  They are designed to appear as application
> layer entities and at the existing IPv6 APIs, but they should not
> appear in actual IPv6 headers.  To make them more like vanilla IPv6
> addresses, they are expected to be routable at an overlay level.
> Consequently, while they are considered non-routable addresses from
> the IPv6 layer point-of-view, all existing IPv6 applications are
> expected to be able to use them in a manner compatible with current
> IPv6 addresses. 
>
> This document requests IANA to allocate a temporary prefix out of the
> IPv6 addressing space for Overlay Routable Cryptographic Hash
> Identifiers.  By default, the prefix will be returned to IANA in
> 2014, with continued use requiring IETF consensus.  This memo defines an 
> Experimental Protocol for the Internet community. 
>
>
> EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet 
> community. It does not specify an Internet standard of any kind. 
> Discussion and suggestions for improvement are requested.  Distribution 
> of this memo is unlimited. 
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked]. 
>
>

---

From: [email-masked]
Date: 28 Apr 2007 23:10:31 -0700

Cc: IETF V6OPS WG <[email-masked]>
From: Fred Baker <[email-masked]>
Subject: Re: application listener discovery in the presence of stateful firewalls
Date: Sat, 28 Apr 2007 23:10:31 -0700
To: james woodyatt <[email-masked]>

On Apr 26, 2007, at 6:34 PM, james woodyatt wrote:

> My biggest worry about IPv6 is that transition may be slowed or  
> even halted because of the basic problem that applications which  
> work over IPv4/NAT today can't be made to work over IPv6 too,  
> without still deploying ALG's everywhere and/or developing the  
> moral equivalent of UPnP IGD and NAT-PMP (minus the UNSAF aspect).

I find that a surprising statement. Maybe you can fill me in?

if an application resides in two systems on the same LAN, or in two  
systems behind the same ALG, they demonstrably don't need the ALG to  
operate. So what the ALG does is enable them to transit a firewall or  
other barrier that the protocol will not.

What would those be?

I can think of some that are erected for administrative reasons.  
Examples include SIP Proxies, which in a NAT world provide a NAT  
traversal strategy and in a stateful firewall world provide the  
transit of the stateful firewall. Since a stateful firewall generally  
allows an interior system to send a datagram out and get a datagram  
in response, these would be about letting a datagram *in* under the  
right circumstances. I'll conjecture that in many cases it might be  
accomplished by triggering the interior device to send a datagram out.

What *other* ALGs do you see?