That's definitely a bug. Mapped addresses should never hit the wire.
Dual stack is quite a bit safer than NAT64/DNS64. The bug you describe
should be fairly trivial to get fixed if someone can isolate which product
actually has the bug. Have you tried the current kernel under the existing
other components? If swapping the kernel doesn't fix it (I think the
mapped address on the wire bugs in the Linux kernel were removed
fairly early in the 2.6 chain IIRC), then it's probably Java.
Owen
Hello,
I was wondering if anyone has successfully deployed a multi WAN product using encapsulation bridge1483 on the Ericsson SmartEdge platform.
Please hit me offline, I can forward you my configs.
Tony
That's definitely a bug. Mapped addresses should never hit the wire.
Dual stack is quite a bit safer than NAT64/DNS64. The bug you describe
should be fairly trivial to get fixed if someone can isolate which
product
actually has the bug. Have you tried the current kernel under the
existing
other components? If swapping the kernel doesn't fix it (I think the
mapped address on the wire bugs in the Linux kernel were removed
fairly early in the 2.6 chain IIRC), then it's probably Java.Owen
It was a fairly recent kernel (2.6.31-19 #56 Ubuntu) and uptime on the
machine I was testing on is a bit less than a year so it hasn't been
updated in a while. I will try it again once that machine gets updated.
I have seen a few bugs in various Ubuntu kernel builds, too. Such as in
one build ND is broken (machine responds to its own DAD probes so it
thinks any address it tries to use is in use) but the previous build and
subsequent build (all of the same kernel version, just different patch
tinkering by Ubuntu) work ok.
The only issue I've faced is RHEL/CentOS doesn't have stateful connection
tracking for IPv6 - so ip6tables is practically worthless.
~Randy
Hmmmm. Interesting. I wonder if this is specific to the RedHat kernel?
Or a problem with v6 support on Linux in general? Perhaps it could be
solved with tweaking which iptables modules get loaded. Ugh. This is why
I don't care for iptables as a firewall. Lost lots of time tracking down
bizarre corner cases due to module issues. Don't get me started on the
number of issues due to distro patching of the kernel.
I haven't used Linux for any serious networking duty for some time. Just
Cisco and pfsense. However the majority of my servers are Linux (Ubuntu
10.10/8.04) (with a couple of windows 2008 servers).
- --
Charles N Wyble (charles@knownelement.com)
Systems craftsman for the stars
http://www.knownelement.com
Mobile: 626 539 4344
Office: 310 929 8793
I've worked around it by compiling custom (newer) Kernels on systems that need
it. Apparently support was added some time around 2.6.20, but of course RHEL5
is still in the dark ages of 2.6.18.
~Randy
(Linux kernels are trying to stick to a release-every-3-months schedule).
RHEL/CentOS 5 is using a 2.6.18 kernel. The needed support for stateful IPv6
landed in 2.6.21 or so (so almost a year after RHEL 5 did its feature freeze).
RHEL 6 is apparently a 2.6.32 kernel so it should be there. Cutting edge kernel
is currently 2.6.38-rc2.
Listen a.b.c.d:80 -> Listen 80
<Virtualhost a.b.c.d:80> -> <Virtualhost *:80>That only works if you have only one address on the machine and.
Actually it works fine on machines with multiple IP addresses for both FreeBSD and CentOS. And IPv6 enabled servers can easily have multiple IPv6 addresses.
If you have addresses that aren't intended for name-based-site-A but
do terminate SSL connections to sites B, C, and D, then you probably
don't want to use * for site A.
Generally, I've found this doesn't really matter too much since the view from the outside world to the server will be funneled via DNS records. Site A can still be referenced by a * in the Apache config since the A and AAAA records will probably reference only the name-based IP addresses for the server while sites B, C, and D DNS records reference site-specific addresses also residing on the same server. The bottom line is that the Apache config can be kept simple and free of hard-coded addresses except where absolutely necessary.
Use hard-coded IP addresses only where required for stuff like SSL-enabled webhosts.
Depends on the complexity of your environment. In a more complex configuration
you can actually save yourself a lot of trouble and confusion later by using a
construct like this:Listen 192.159.10.7:80
Listen [2620:0:930::dead:beef:cafe]:80
Listen [2620:0:930::400:7]:80
<VirtualHost 192.159.10.7:80 [2620:0:930::400:7]:80 [2620:0:930::dead:beef:cafe]
:80>
ServerName www.delong.com
I'd do that only for the SSL-enabled sites. Otherwise the generic name-based Apache config should work fine for just about everything else.
Antonio Querubin
e-mail/xmpp: tony@lava.net
RHEL has the eMRG kernel available that is post-2.6.18, for RHEL5.
However, RHEL's 2.6.18 kernel has many many things backported from much more recent kernels, including features like ext4. Saying that it's an old kernel isn't completely true; it's kind of like saying a '67 C2 Vette with a 327 has an old engine (after all, why not the 427?), but what you don't see is the sixty-thousandths overbore, 18 degree BowTie heads, forged crank, a 1300CFM Holley Dominator 4500 on an Edelbrock Victor Glidden single-plane port-matched 18 degree intake, along with Flowmaster long tube headers, long lobe COMP cam, and high stall torque converter that makes it more than just an old 327... Sorry, dream car there.... and, yes, I'd rather have the tricked-out 327 small block than the 427 big-block....although that carb on that intake isn't the most street-friendly combination ever imagined....
Don't judge a kernel by the superficial version number; look for the performance parts under the hood, and maybe even under the valve covers....
Or at the very least document this in plain site in the IPv6 section of the docs. Their non-RFC-compliant behaviour is a hidden land mine.
Antonio Querubin
e-mail/xmpp: tony@lava.net
As long as you're willing to run your iptables through a modification filter to generate the corresponding ip6tables you should be ok. The following sed script might come in handy.
s/-p icmp --icmp-type any/-p icmpv6/
/-m state --state ESTABLISHED,RELATED/ {
s/-m state --state ESTABLISHED,RELATED/-p udp -m udp --dport 32768:61000/p
s/udp/tcp/g
s/61000/61000 ! --syn/
}
s/-m state --state NEW //
s/224.0.0.251/ff02::fb/
s/icmp-host-prohibited/icmp6-adm-prohibited/
Modify as needed. YMMV.
Antonio Querubin
e-mail/xmpp: tony@lava.net
What Owen meant was that if you expect it to answer *only* for a.b.c.d:80,
and *not* to answer for other addresses/interfaces, you may be in for a
surprise (consider a DMZ host where you have:
outside world - 128.257.12.2
inside facing - 192.168.149.149
VirtualHost 198.168.149.149:80 # super-sekrit corporate internal site
Changing that VirtualHost to *:80 will probably cause some grief. 
Additionally for DNS don't forget to add IPv6 glue for the nameservers
for your zones to the parent zones.
For named in particular listen-on-v6 needs to be specified as it
is not on by default e.g. "listen-on-v6 { any; };". Named will ask
questions over IPv6 by default even if it isn't listening on IPv6.
It's actually pretty well known and it is documented in several places in plain
sight.
They're quite proud of their brokenness and they extol the virtues of the
allegedly improved security profile it provides.
I think Rolland Dobbins has coined a good term for it... "Security Theater".
(Though this strikes me as being more like "Security Circus")
Owen
Exactly... That is one of MANY examples of the kind of potential
for abuse I was attempting to describe.
Admittedly, if you put your Super-sekrit corporate internal site on a
DMZ host, you arguably deserve what happens, but...
Owen
Where?
A search for IPV6_V6ONLY in the FreeBSD Handbook yields nothing. You'd think the brokenness would at least be mentioned in the handbook.
A similar search of the FreeBSD FAQ yields a bunch of hits but none that really mention the RFC brokenness.
The only place where I've seen this behaviour mentioned in the past is in bug reports. And the responses to those were that the non-compliant behaviour was preferred but would/should be more clearly documented. Years later, the documentation is still lacking.
Antonio Querubin
e-mail/xmpp: tony@lava.net
It's actually pretty well known and it is documented in several places in plain
sight.Where?
A search for IPV6_V6ONLY in the FreeBSD Handbook yields nothing. You'd think the brokenness would at least be mentioned in the handbook.
A similar search of the FreeBSD FAQ yields a bunch of hits but none that really mention the RFC brokenness.
The only place where I've seen this behaviour mentioned in the past is in bug reports. And the responses to those were that the non-compliant behaviour was preferred but would/should be more clearly documented. Years later, the documentation is still lacking.
The FreeBSD releng/core community has consistently done odd things that have caused them to lose favor in my mind, ranging from:
a) Lack of support of serial console other than com1 without rebuilding the kernel, boot blocks, etc.
b) soliciting feedback in -RC releases and not fixing defects in the -RELEASE, nor updating errata documents regarding defects they have refused to fix
c) Generally being arrogant and rude to the user community that may not want to manage a large set of systems by "make buildworld"
These are just a few of my unfavorite things regarding that community. I have the things I like, but the things that I don't continue to outweigh and feed into regret of using their systems. At least when I freebsd-update now, I don't need to edit german ISDN rate files anymore, but the fact that I had to in the first place is problematic to say the least.
- Jared
REFERENCES:
b: 140712 – [fxp] fxp driver starts with rxcsum on
Of course, anybody expecting a current IPv4 geolocation service to
provide accurate information over IPv6 over the next couple of years
is wildly optimistic (with all due respect to people in that business,
but just sayin' good luck with that...)
Maybe you'll get some consistency about which continent they're on
based on the RIR the addresses came from, but even that's probably
dodgy if the address belongs to Hurricane Electric or Sixxs or some
other popular tunnel broker, and maybe you'll get some consistency on
"is it the same /56 as last time?", and maybe some of them will start
doing tricks like putting web bugs for
"ipv4tracker.geolocator-example.com" and
"ipv6tracker.geolocator-example.com" on the same web pages to try to
start building correlation information, and if course you need your
application that uses the information to speak IPv6 and handle 128-bit
records and not just 32-bit.
The IPv6 geo databases actually tend to be about on par with the IPv4
ones from what I have seen so far (which is admittedly limited as I don't
really use geolocation services). However, I still think it is important for
people considering deploying something as you described to be aware
of the additional things that may break and factor that into their
decision about how and what to deploy.
Owen