[initscripts-ipv6] Bug (or enhancement) in 6to4 scripts (NAT)...

[Michael H. Warfield]

On Mon, Aug 30, 2004 at 08:59:57AM +0300, Pekka Savola wrote:
> On Sun, 29 Aug 2004, Michael H. Warfield wrote:
> > On Sat, Aug 28, 2004 at 09:21:09AM +0300, Pekka Savola wrote:
> > > IPV6TO4_IPV4ADDR has two purposes: it can be used when there are
> > > multiple IPv4 addresses and you want to pick which one to use to build
> > > the prefix. It was also imagined to be used to pass through the NAT
> > > when the NAT has been configured to pass the protocol-41 packets to
> > > specific internal host.
> > 
> > > Note that this only supports one 6to4 router behind a NAT.  Multiple
> > > ones won't work.  And you need to configure the NAT to forward all
> > > proto-41 packets to that node.
> > 
> > 	Actually, this is incorrect on both counts.  

> No, this is wrong, please think again.

	Well, it seems to work.  At least for clients behind the NAT device.
Or if you are building a "road warrior" type tunnel.  Remember, too,
you don't always have control over that NAT device, even assuming that
it even supports protocol 41 passthrough.  I'm thinking of the roadwarrior
case where I sit down at a hotel (or conference center, or friend's house,
or on vacation - happens a lot, couple times a month at least) and fire
up my laptop and I have to cross a NAT box (or more if it's wireless and
we're double NAT'ed through it and a cable modem or such) just to get to
my network.  Up until now, I've been firing up an entire IPSec NAT-T
VPN just to tunnel IPv6 back to my tunnel anchor at a colo facility.
Now I find that, far far more often than not, I can just fire up 6to4 with
the proper addresses, and it just works.  I can't go to that hotel and
tell them "can you please enable protocol 41 passthrough in your NAT
device for me?"  They'll look at me like I grew three heads (after they
regain focus from trying to figure out what I just said).  I've still got
to test it out in a lot more locations on the road yet, but it looks pretty
good for everything I've tested so far.  Roadwarrior mode, for me at
least, seems to be the big use for this particular mode of operation.
Cases where it fails, I can still fall back to the more complicated
tunnels using IPSec NAT-T or ppp over ssh or something.

	I will admit that it doesn't support the case of trying to
advertise a server behind a NAT device on 6to4.  But, in my case, that's
not all that interesting.  In my mind, if you are already going to the
effort of setting up a server you want to advertise, then the effort to
set up a better gateway is not, incrementally, that much greater.
Qualitatively, you've already stepped up above the simple case and it's
a much more limited.

	Then too, supporting protocol 41 NAT doesn't preclude supporting
6to4 over 41 passthrough, either.  Both methods can co-exist.  And if
someone has a device that doesn't support protocol 41 passthrough (or
they have to work across a device they don't control and can't access) and
they don't care about advertising a server, they can still get access
through the protocol 41 NAT.  If they want to advertised a server,
they're probably going to have to upgrade the gateway NAT device either way.

> > Again, according
> > to draft-palet-v6ops-proto41-nat-03.txt they found that 80% - 85% of NAT
> > devices on the market at that time support a true NAT of protocol 41.

> Yes, but 6to4 support requires more than just proto41 forwarding.

	Full 6to4 support, servers and everything, sure.  I'll grant
you that.  But to just support clients, it's fine.  It's a case which
does work but is not supported by the current scripts.  But it can be.
It's not that big of a deal and it could be very useful.

	One thing I'm not certain about (and I'm surprised the issue
wasn't raised) is whether the anycast helper gateways will work over
the NAT translation.  Outbound should be fine but do they use the
anycast address as the source IPv4 address for the return packets or
do they use their unicast address?  That's another potential breakage
that I'm just getting around to exploring.  I don't generally run
into that very much with what I do, anyways.

> > 	That means it does not require protocol 41 pass through.  It
> > translates the address on the way out and detranslates it on the way
> > back based on the remote IPv4 address.  It actually works.  I've now
> > done it.

> Sure, this works just fine for configured tunneling, but if you read
> my message carefully, I mentioned a scenario where this does not work,
> and *cannot* work if you think it through.

> All of this can work if the NAT support proto-41 state for packets
> which originate behind a NAT, and replies come back during the
> lifetime of that state. But that's not all to it.

	Doesn't need to be all of it.  It's a specific case that can
work and does work and works with far more of the NAT devices than
trying to set up protocol 41 passthrough.  Has anyone actually tried
to survey how many NAT devices allow you to configure a passthrough
on anything other that TCP or UDP?  The devices I have on hand, or have
access to through friends and family and our testing labs at work, just
give to options to enter a port number and TCP or UDP for the passthrough
and no way, which I've uncovered, to configure other protocols.  A couple
of years ago, we called the support departments for several vendors
(IIRC, we called D-Link and, maybe, Linksys, and others) and asked them about
a passthrough on protocol 41 and they had technical people get back to
us saying it wasn't available and there were no plans to support anything
other than TCP or UDP for passthrough.  But the protocol 41 NAT seems
to be supported (even if by accident).  I guess, if you were trying to
support a server using this scheme, you would have to get a better
gateway in any case, but then you could get something decent that could
support IPv6 anyways.

> But it does *NOT* work when you publicize e.g., the 6to4 address of
> your webserver, and someone, using 6to4 addresses, tries to contact
> the server.  The encapsulated packet comes to the NAT, but the NAT has
> no state for that particular IPv4 address (because the internal hosts
> have not communicated with it).  Further, if there are multiple 6to4
> routers inside the NAT, the NAT cannot even know which one this is
> destined.

	I don't find the server case nearly as interesting, simply because
if you are setting up servers and want to advertise servers, then you
can put a little more effort into your gateway (like installing a Linux
server as the gateway) and handling 6to4 on the gateway itself.  Seems
to me that the very effort of even finding a NAT device that's going to
support protocol-41 passthrough is going to make alternatives, such as
a Linux gateway, more attractive.  For the server case, I'm not even
sure I would want to support a server on 6to4 behind a NAT, given that
it's easy enough, now, to get a configured tunnel from a tunnel broker
for free.  A server behind a NAT device on 6to4 just seems a little
counter productive, even if you have a gateway that's capable of
supporting it.

> Hence, proto-41 does not work correctly and completely with 6to4
> without manual configuration of proto-41 at the NAT box.

	Do you have a list of devices that actually allow you to do
this?  I haven't found any.  I'm sure there are some, but the vendors
don't seem to interesting in it from my conversations with them.

	Still doesn't help with the case where you don't control or
can't access that NAT device.  There are lots of them out there.

	Protocol 41 NAT doesn't work completely, but it does work for a
large set of valid cases and it doesn't interfere with the passthrough case.
I'm not sure what you mean by "does not work correctly", though.  For
the cases were it works, it seems to work correctly.  For the cases
where it doesn't work, it simply doesn't work and is not "complete".
So I agree with the "doesn't work completely" part.

> (Configured tunneling can work correctly and completely without manual
> configuration, even for multiple routers.)

	This is true.  And the client case works as well (at least it sure
seems to).  It also supports multiprotocol applications (probably better
than true NAT on IPv4) since the IPv6 is still uniformly addressed, even
with reverse callbacks (such as port mode ftp).  The "advertise a server
case" doesn't work, but I would argue that you should have a better
gateway for that case anyways.

> > 	That also means it does not require a special configuration
> > on that NAT device for the 6to4 gateway.  As long as it does a blind
> > IPv4 -> IPv4 NAT and reverses the NAT on the way back, it works.

> For sessions initiated in one direction, yes.  For the other, no.

	But that's a valid case and it's a valuable case and it's a case
that's not currently supported.  The server case can be managed through
other mechanisms without discarding this case.

> > 	It also means that multiple systems behind the gateway CAN
> > use 6to4 (but, due to another design mistake, the 6to4 address is
> > not unique because the EUI address is ::1 for the same prefix).  If
> > each node behind the NAT gateway had a unique EUI address, they would
> > not collide on the local net and, as long as they were NOT going to the
> > same site on the global net, they could share the same NAT gateway.  With
> > the addition of table caching in the NAT gateway that included the EUI
> > address (which none that I know of do now) even the limitation that two
> > nodes could not access the same external site could be handled by keying
> > off of internal EUI (similar to indexing on port number).

> This was considered a non-goal.  If the NAT box would have to support
> looking at the IPv6 packets, it could as soon be upgraded to act as
> 6to4 router on its own.

	True...  Once you have the NAT box examining protcol 41 and the
IPv6 traffic, then you might as well get support on there for IPv6 as well.
I agree with you there.  The Linux based LinkSys devices are almost there
(just a little more memory, if you please).

	Well...  The NAT device has to support protocol 41 passthrough
as well and that seems to be much less common than simple protocol 41 NAT.
Yes, I know I probably don't possess a statistically valid sampling of
devices to make that statement.  Can anyone point me at a chart or
survey comparing the two features?  That IETF draft alluded to a
survey of device manufacturers but didn't indicate where the survey
results could be found.  They said 80% to 85% of NAT devices on the
market support this (protocol 41 NAT).  What percentage support configuring
a passthrough on protocol 41.  None of the devices I've been able to
lay my hands on from several manufactures seem to support anything other
than TCP and UDP.  You even need to use IPSec NAT-T (IPSec over UDP) with
most of them because they aren't going to pass 50/51 through either.  I'm
happy that this works for the client case, once the scripts are patched, and
it can be made to work over devices which do not even support protocol 41
passthrough.  Servers and connections initiated from the outside in
won't work, I'll grant you that.  But the client direction can work and
does work, even with devices which can not even be configured for
protocol 41 passthrough.

> [snip to the end]

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

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20040830/129dddbc/attachment-0001.sig>