[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The argument for writing a general purpose NAT for IPv6



On Apr 17, 2007, at 02:09, EricLKlein@softhome.net wrote:
On 2007-04-17 00:55, james woodyatt wrote:
...
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.
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.
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.

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