André - Almost have it right. As I understand IPv6, yes there is supposed to be some mapping of IPv4 to IPv6 available, if you've got all the right stuff. I don't know enough about it to say when/where/how that takes place. However, Microsoft, in their infinite wisdom, give us two protocol stacks, each configurable separately. As of Server 2008 (and Window 7 & Vista), you are given both, and you can't remove either one. What I reported is what you actually see under a Windows Server 2008 installation. It definitely looks to me to the Tomcat and/or APR layer that's the culprit, not anything further down the list. But I'm a layman, not one of the Tomcat clergy, so I can't say for sure. The actual breakdown of things is as follows:
1) If not using native libraries/APR, then Tomcat listens on both IPv4 an IPv6 for a specific <Connector>. 2) If using native libraries/APR, then Tomcat only listens on IPv6 unless you explicitly set up an IPv4 address parameter in the <Connector>. If there is no IPv6 stack, then it will use IPv4 - but you can't uninstall IPv6 on a modern MS OS. You can disable it (uncheck it), but the system still has the stack loaded, and Tomcat still configures for IPv6. 3) The SHUTDOWN/Server connector enforces 127.0.0.1, which might be a problem if anyone sets up an IPv6-only configuration. Couldn't swear to that, since I have no intention of running IPv6-only anytime soon. 4) Review my netstat entries and you'll see that the AJP entry acts like any other connector according to 1) & 2) above. 5) No way to force one or the other that I've found. Jeff -----Original Message----- From: C Warnier [mailto:a...@ice-sa.com] Sent: Friday, May 07, 2010 1:54 PM To: Tomcat Users List Subject: Re: Re : Re : Re : Tomcat 5.5.29 does not accept connections from outside Jeffrey Janner wrote: (a lot of useful stuff) Thanks for all this info. Honestly, I have not really looked deeply into IPv6 yet, and I am not sure I understand the implications very well. My naive idea was that this stuff was really cool, opened up a lot more address space, that IPv4 addresses had somehow been mapped to a sub-range of IPv6 addresses, and that there was always some kind of "automatic IPv4 to IPv6 translation" going on in the background. I guess it's not that simple, and I'll have to brush up on my IPv6 stuff. Another impression I'm getting now, is that Tomcat-wise, things are not very clear in that respect. Or maybe it's just the documentation which is lagging a bit. In all fairness, it is probably not the Tomcat layer that is the thing here, it is the Java JVM I guess, or maybe even deeper into the OS. If I summarise what I've seen so far, in dummy's terms : - if you are using APR for the HTTP Connector, then it is always IPv4 (or maybe only up to version X) - if you are using the non-APR HTTP Connector, then it is IPv6 by default, if this is the platform's default ? Except if you force IPv4 by specifying "0.0.0.0" as the address to listen on. - the SHUTDOWN connector (default port 8005) seems to be always IPv4, probably because internally it forces listen address 127.0.0.1 (Can this be a problem ?) - what about the AJP Connector ? Does that one also depend on whether you are using APR or not ? (I don't remember if for that one, you /can/ specify an address; I'll check) - is there a way to force the JVM to use one or the other ? I saw the -D parameter indicated by Chuck before, but the OP seemed to say it had no effect. On what does that depend ? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org ******************************* NOTICE ********************************* This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments.
