Bug (or enhancement) in 6to4 scripts (NAT)...

[Michael H. Warfield]

Hey guys, Peter, et al...

	Me again.  :-)

	Cross posted to Fedora-list and RedHat-list since this also
involves the RedHat "ifup-ipv6" script.  I'll probably also file
a bugzilla bug report on this.

	I've been working on a custom distro that communicates over IPv6
only (over various 6over4 tunnels when IPv6 native is not available) where
IPv4 is completely cut off for tcp, udp, and icmp.  Actually working
pretty neat.  Been working on autoconfiguring 6to4 in the case where
we are behind a NAT device.  According to an IETF survey, 80% of the
NAT devices on the market SHOULD support this (maybe more, now, since
it's actually pretty simple to do).  But I could never get it to work.
Anywhere.  No matter what NAT device.

	Sooo...  It seems...  Now that I have this distro I'm trying
to assemble, I needed to get to the root of that problem.

	I have run into a problem and it appears to be a bug in the
init scripts handling 6to4.  The problem that's been wracking my
brains is that I could NOT get 6to4 to work over NAT, even when I
specified the correct IPv4 address using IPV6TO4_IPV4ADDR in the
RedHat/Fedora configuration files.  If I didn't specify the address,
I simply got nothing back, which was pretty much to be expected.  If
I DID specify the IPv4 address, I got immediate unreachable errors
from ::1 (localhost).  That didn't make ANY sense.

	Well, digging deeper into this I discovered a problem in the
ipv6_add_6to4_tunnel() function.  When you specify the NAT IPv4 address
as the localipv4 to this function, it correctly builds the IPv6 6to4
prefix but then it uses that SAME IPv4 address as the local end of the
tunnel.  This is wrong.  This is very bad.  You don't have that address
as legitimate on that local machine.  You have to build the prefix using
the GLOBAL IPv6 address of the NAT gateway and use the LOCAL IPv4 address
of the interface to build the tunnel.  When I do this manually, IT WORKS!
6to4 NAT's over a Linux based NAT gateway perfect.  Gotta try it out on
more devices, but that final kludge definitely rang that bell and tcpdump
confirms absolute proper NAT operation on the 6to4 traffic.

	So, obviously there is a bug in the ipv6_add_6to4_tunnel() function
where it uses the same address for the prefix and for the tunnel.  This
can only work when there is no NAT device.

	Now, of course, this interpretation depends on interpreting
that "IPV6TO4_IPV4ADDR" parameter as being there to support 6to4 over
NAT.  If it is, then it's a bug.  If it's not, then I'm not sure what
it is there for (since overriding the local IPv4 address is unlikely
to work) but this is then an enhancement, assuming the ipv6_add_6to4_tunnel()
function was never meant to support NAT.  But supporting it seems
easy enough, at this point.

	This means that both addresses (the global NAT address and the
local interface address) have to be passed to that function.  That means
mods to both the function and to the scripts calling the function (the
RedHat scripts).

	I'm not sure of the "best" way to fix this problem.  Adding
an extra optional parameter to the end of the list ($5) for the other
address and then getting the function to get it right seems to be
the "correct way", but somewhat inelegant (elegant would be to
shift the parameters so that $2 is the global address and $3 is the
local address and everything after that is shifted over one).

	Another choice (one that I'm thinking of using in the short
run) is to modify $2 to be formated something like PPP style
{local address}:{remote address}.  That would, at least, be compatible
with the existing ifup-ipv6 scripts and make the enhancement for 6to4
NAT relatively painless.

	For that...

	ipv4address			both local and global address (non-NAT)
	ipv4address:ipv4address =>	local_address : global_address

	This would actually have the side benefit that you COULD
make this work without modifying the RedHat scripts, merely by added
the ordered pair in as that parameter in the config file (DUCKS!  Yes,
it's a butt ugly kludge, so sue me).

	I've got a little web page up that lets me "ding" it and returns
my IPv4 address, so (assuming port 8008 is NAT'ed the same way protocol 41
is NAT'ed - not a real good assumption, I'll agree) I can pretty much
autodetect when I'm NAT'ed (ideally, I would like something I could
"ping6" which would return an ICMP error with the correct addresses in
the payload, but that's another project at the moment) and then get the
6to4 set up correctly for operation behind a NAT device.  This would be
a VERY GOOD thing for lots of people on DSL and broadband who are sitting
behind NAT devices which ARE perfectly capable of NATing and routing
IPv6.  :-)

	If the RedHat people go in there and fix that problem, they might
also add code to pass the suffix of the real interface into that function
so the 6to4 address has the same lower 64 bits as the ethernet interface
(or ::1 if it's and interface that has no MAC address).  That, plus the
fact that there seems to be no hooks hooking in the 6to4 logic into
the PPP up/down scripts.  :-(

	Regards,
	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/20040826/b65771c0/attachment-0001.sig>