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