Pete French wrote:
I have been running IPv6 on all of my FreeBSD work systems for
years. All of my mail (including this message) are sent/received by IPv6
and I have not had any problems, but I am on a network that is fully
IPv6 enabled, so no tunnels are involved.
That's good to know. I have one box on the live internet (mail.twisted.org.uk)
which is runnign 6.2-STABLE and using 6to4 to provide IPv6 to those whowant it.
Some of our outgoing mail gets delivered over IPv6, but none of our
incomming does. However it does seem to behave itself.
I do know that there will be a major re-write of IPv6 support in V7 to
integrate the KAME code into the rest of the network as KAME is not
longer separately developed. I'm not sure how this will impact things,
That was going to be the next point where I tested it (when V7 comes
out). My home machine works more-or-less ine using IPv6 on 6to4,
with the only problems being when ftping large files to/from twisted.org.uk
which show a random disconnect after 10-20 minutes of transfer.
My bigger problem is trying to distribute my IPv6 address to machines
behind the single box which faces the outside world (as thats what IPv6
is good for right ? No more NAT?). These boxes work in so far as they
can all see and ping IPv6 addresses and make and receive TCP connections.
But if, for example, I make a TCP connection to www.kame.net then I get
the first chuink of data but then a freeze for a long period of time before
the rest of the data arrives. This does not happen from the direct machine,
it sees all the data at once.
Unfortunately that problem makes IPv6 useless for me on the inteernal network
behind the box, so it's been disabled. I am reluctant to deploy it on
work machines for the same reson. Diirectly connected boxes may work fine
but actiually trying to use IPv6 to get rid of NAT doesn't seem to work right.
Sadly I haven't had any time to investigate further.
I'm no ipv6 wiz but that sounds awfully lot like slow path mtu discovery.
Perhaps you could adjust the tcp6 mss to account for the difference in mtu?
On tcp (v4) it was MTU - 40 bytes but on ipv6 it could be more.
If you by any chance used ms windows behind that ipv6 router then that
would account for the slow reaction to the icmp packet indicating packet
was too big but dont-fragment flag was set (or whatever the ipv6
equivalent is)
--
Sten Daniel Soersdal
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
