-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, All the recurring threads about prefix length, security posture, ddos, consumer CPE support have been somewhat interesting to my service provider alter ego. Ipv6 is definitely on folks minds this year. The threads seem a lot less trollish as well. It appears some significant progress is being made, and peoples opinions are firming up. Hopefully this will help move ipv6 adoption forward. I have recently turned up an ipv6 tunnel with he.net and have end to end connectivity. I'm using pfsense as my routing platform. It was pretty easy (about 10 minutes of total work I think). So I can connect to various ipv6 enabled sites on the interwebz. This seems to be the first step in deployment. For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard? Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP. Feel free to point me at any good manuals and say RTFM :) - -- Charles N Wyble (charles@knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQGZvAAoJEMvvG/TyLEAt9ykP/ROLSWz3LmAF78OMBEhWEMvX MjOVR2QK6kQ3byV8WLro95tCOuyo8L8fUC60KyFh4XRsedb7xk6S8cTER80zmGzG rOAFVpNyJ1QzCcf4MYpj8xHn9zM6Fywft4VzKQEgDvlV8yD0VZKJi+fNj4noZ5oK tmM1s9Is5db3d5ldrC6M54TQJsbaZiuz+FrFtpkENraJIWlOeU3laM6kvwzvYpok BKtnaY6zBq42QovpJ+MU+lmanCB6Z0r3e2cSB+N7XJL0Va/Y2IW/eZn35S+dE3xk y7RPSZu2jDxJ6atQJVIBpjfL6oqUUr+0RHc+gX4VJyOrwpEuJQ/GvTiRDTUZkA0A twhvQnS6yc5G8L+iwID4YqkVKNCFcJUtAHUntqmy1FqTe9iQSlZdUPPhKrkRE7zW B2S2T0Lv6a/neHU5yfsGjiYbIAy7keXoiMPbR4ZJxC/KkogfWNgMZBVpjGVn0NI4 COOymyFYgvQFiXIpvmpQn0iLFcWmmGdwV2DPvxMArdmfw2SeyipJiBSeeEbb4ZG4 kw1LOrI7+OGnoDEByAtkZPh42wAbXbrSw9WeWvphAsQ2dAmASqXUKuHTDXd1laCC yi37NTRmWACNHKcVEhpk3saJDCsPPVx6ECYfhSsSALZDn6696BvFXZnN2423Fmk7 dtMKM38+rxz9r4IL5O+n =Mi6R -----END PGP SIGNATURE-----
Bind and apache work with v6 out of the box, and have for years. As I understand it, when a client requests a particular domain of yours and gets an A and an AAAA, the client will default to the AAAA (assuming it's on a v6 network) and attempt to communicate as such. Failing that, it will fall back to the v4 A record. So in short, yes, it's as simple as telling the daemons to listen on your v6 addresses and adding the AAAA records. Just think how happy your 1 client/customer using IPv6 will be ;-) -Jack Carrozzo On Wed, Jan 26, 2011 at 1:22 PM, Charles N Wyble <charles@knownelement.com>wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
All the recurring threads about prefix length, security posture, ddos, consumer CPE support have been somewhat interesting to my service provider alter ego. Ipv6 is definitely on folks minds this year. The threads seem a lot less trollish as well. It appears some significant progress is being made, and peoples opinions are firming up. Hopefully this will help move ipv6 adoption forward.
I have recently turned up an ipv6 tunnel with he.net and have end to end connectivity. I'm using pfsense as my routing platform. It was pretty easy (about 10 minutes of total work I think). So I can connect to various ipv6 enabled sites on the interwebz. This seems to be the first step in deployment.
For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard?
Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP.
Feel free to point me at any good manuals and say RTFM :)
- -- Charles N Wyble (charles@knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJNQGZvAAoJEMvvG/TyLEAt9ykP/ROLSWz3LmAF78OMBEhWEMvX MjOVR2QK6kQ3byV8WLro95tCOuyo8L8fUC60KyFh4XRsedb7xk6S8cTER80zmGzG rOAFVpNyJ1QzCcf4MYpj8xHn9zM6Fywft4VzKQEgDvlV8yD0VZKJi+fNj4noZ5oK tmM1s9Is5db3d5ldrC6M54TQJsbaZiuz+FrFtpkENraJIWlOeU3laM6kvwzvYpok BKtnaY6zBq42QovpJ+MU+lmanCB6Z0r3e2cSB+N7XJL0Va/Y2IW/eZn35S+dE3xk y7RPSZu2jDxJ6atQJVIBpjfL6oqUUr+0RHc+gX4VJyOrwpEuJQ/GvTiRDTUZkA0A twhvQnS6yc5G8L+iwID4YqkVKNCFcJUtAHUntqmy1FqTe9iQSlZdUPPhKrkRE7zW B2S2T0Lv6a/neHU5yfsGjiYbIAy7keXoiMPbR4ZJxC/KkogfWNgMZBVpjGVn0NI4 COOymyFYgvQFiXIpvmpQn0iLFcWmmGdwV2DPvxMArdmfw2SeyipJiBSeeEbb4ZG4 kw1LOrI7+OGnoDEByAtkZPh42wAbXbrSw9WeWvphAsQ2dAmASqXUKuHTDXd1laCC yi37NTRmWACNHKcVEhpk3saJDCsPPVx6ECYfhSsSALZDn6696BvFXZnN2423Fmk7 dtMKM38+rxz9r4IL5O+n =Mi6R -----END PGP SIGNATURE-----
Thus spake Jack Carrozzo (jack@crepinc.com) on Wed, Jan 26, 2011 at 01:38:48PM -0500:
As I understand it, when a client requests a particular domain of yours and gets an A and an AAAA, the client will default to the AAAA (assuming it's on a v6 network) and attempt to communicate as such. Failing that, it will fall back to the v4 A record.
This is true for now. See http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6 for a proposal on how this could change. Dale
From: Charles N Wyble Sent: Wednesday, January 26, 2011 10:23 AM To: nanog@nanog.org Subject: Ipv6 for the content provider
For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard?
Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP.
Feel free to point me at any good manuals and say RTFM :)
Most load balancers these days will allow you to provision an IPv6 virtual IP that balances to v4 servers. So you can provide services over v6 without a lot of changes inside your network. You will need a DNS server that hands out AAAA records though.
On Jan 26, 2011, at 10:39 AM, George Bonser wrote:
From: Charles N Wyble Sent: Wednesday, January 26, 2011 10:23 AM To: nanog@nanog.org Subject: Ipv6 for the content provider
For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard?
Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP.
Feel free to point me at any good manuals and say RTFM :)
Most load balancers these days will allow you to provision an IPv6 virtual IP that balances to v4 servers. So you can provide services over v6 without a lot of changes inside your network. You will need a DNS server that hands out AAAA records though.
And if your servers behind the LB aren't prepared for it, you lose a LOT of logging data, geolocation capabilities, and some other things if you go that route. Owen
And if your servers behind the LB aren't prepared for it, you lose a LOT of logging data, geolocation capabilities, and some other things if you go that route.
Owen
I can't imagine an LB vendor who would sell a v6 to v4 vip solution who wouldn't provide a way to inject the v6 addr in to the request as an additional header? I suggest a naming-and-shaming is in order -- David Freedman Group Network Engineering Claranet Group
On Jan 26, 2011, at 11:10 AM, David Freedman wrote:
And if your servers behind the LB aren't prepared for it, you lose a LOT of logging data, geolocation capabilities, and some other things if you go that route.
Owen
I can't imagine an LB vendor who would sell a v6 to v4 vip solution who wouldn't provide a way to inject the v6 addr in to the request as an additional header? I suggest a naming-and-shaming is in order
Sure, but, if you're not prepared to parse, log, and deal with that header, then, you lose, right? Note I said "IF your servers behind the LB aren't prepared for it..." Owen
And if your servers behind the LB aren't prepared for it, you lose a LOT of logging data, geolocation capabilities, and some other things if you go that route.
Owen
Relying on IP address for geolocation is actually quite ridiculous though I do realize that many people seem to believe that you can map an IP address to the physical location of the originator of the data, at least to the country level, but I suppose some people will sell you anything. We haven't seen any problem with logging data so far in our testing.
On Jan 26, 2011, at 11:22 AM, George Bonser wrote:
And if your servers behind the LB aren't prepared for it, you lose a LOT of logging data, geolocation capabilities, and some other things if you go that route.
Owen
Relying on IP address for geolocation is actually quite ridiculous though I do realize that many people seem to believe that you can map an IP address to the physical location of the originator of the data, at least to the country level, but I suppose some people will sell you anything.
We haven't seen any problem with logging data so far in our testing.
I don't disagree, but, since people like Wells Fargo are using it as a security check (ask me about my experiences trying to log in from Rwanda to check on a mortgage payment some time), things that potentially make it even more broken than it is are worth pointing out to administrators that may be stuck implementing IPv6 on sites that may have such dependencies. Owen
On 1/26/11, Owen DeLong <owen@delong.com> wrote:
And if your servers behind the LB aren't prepared for it, you lose a LOT of logging data, geolocation capabilities, and some other things if you go that route.
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. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
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 On Jan 28, 2011, at 4:02 PM, Bill Stewart wrote:
On 1/26/11, Owen DeLong <owen@delong.com> wrote:
And if your servers behind the LB aren't prepared for it, you lose a LOT of logging data, geolocation capabilities, and some other things if you go that route.
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.
-- ---- Thanks; Bill
Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
On Fri, Jan 28, 2011 at 8:04 PM, Owen DeLong <owen@delong.com> wrote:
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
That isn't going to be the case going forward, I don't believe because our allocation from ARIN will likely be used globally and others are likely to come to the same conclusion. While I had initially considered obtaining regional allocations for operations in that region, the overhead of dealing with multiple registries, differing policies, multiple fees, etc. didn't seem worth the trouble. The ARIN allocation will likely be used in EU and APAC regions in addition to NA.
Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP.
It might be that simple, it might not. Depends on your application. For the DNS and Mail, it should be pretty much that simple. I don't know about the state of Postfix (don't use it), but, sendmail has been IPv6 ready for years and I'm running with it no problem. As to the web, Apache is fully IPv6 ready and that's easy. It will take IPv6 addresses in all the same places you would configure IPv4 addresses. You do need to enclose the address portion in brackets with the port number outside the brackets. e.g.: 2620:0:930::400:7 on port 80 = [2620:0:930::400:7]:80 Other considerations that may be important: 1. Load balancers 2. Log parsers 3. UI stuff that accepts or reports IP addresses Application Site Administration CMS 4. Databases that contain IP address(es) 5. Other tools, files, etc. that may interact with IP addresses All of those things will need additional attention as you add IPv6 capabilities to your site. Some sites have to worry about all 5. Some sites don't have to worry about any of these things. I was able to do all the web sites I host at home just by adding the appropriate Apache configs and putting in the AAAA records next to the A records. Took me about an hour for a couple dozen sites. I've received exactly zero user complaints since the IPv6 implementation. More complex environments may take considerably more effort. Owen
On 01/26/2011 07:46 PM, Owen DeLong wrote:
Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP.
It might be that simple, it might not. Depends on your application.
For the DNS and Mail, it should be pretty much that simple. I don't know about the state of Postfix (don't use it), but, sendmail has been IPv6 ready for years and I'm running with it no problem.
I run a low traffic mail server with Postfix, and setting up IPv6 was as easy as adding AAAA records for the MX-es and enabling 'inet_protocols = all' in main.cf -Lorand Jakab
On 26/01/2011 20:22, Charles N Wyble wrote:
For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard?
Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP.
I haven't worked with Postfix recently but Exim on a default config will start talking IPv6 as soon as it has connectivity. Just be careful of this since you need to make sure that all your rDNS, SPF, etc ducks are in a row before you give it IPv6 since it can start delivering mail via IPv6 with very little encouragement. With Apache I've had some funnies with how it binds (or fails) to IPv4 and IPv6 sockets at startup. Once you're over that hurdle I've found that the majority of open source web apps either support IPv6 or are designed correctly to not be impacted by other layers in the network stack. Its important to keep a close eye on logs and also don't roll out to all your servers in one go. The gradual migration to dual stack has been fairly painless for me. -- Graham Beneke
In a message written on Wed, Jan 26, 2011 at 10:22:40AM -0800, Charles N Wyble wrote:
For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard?
Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP.
The layer 3 part for you is really simple. Here's a deployment model we use a number of places. I'm going to assume you have a /48, from ARIN or your upstream. Lay out your networks as: AAAA:BBBB:CCCC:<vlan>::/64 The AAAA:BBBB:CCCC::/48 was given to you by ARIN/your upstream. For VLAN I recommend being human friendly and making vlan 10 be AAAA:BBBB:CCCC:0010::/64, even though that's technically 16 in Hex. The vlan's consume 4096 of your 65536 subnets, so you still have many more to play with. Want to know what address to configure, well, you can guess if you know the vlan number. We then also do the same thing with the address, if it's a static server. Say the server was 10.2.50.210. We re-use the 210 part, and get AAAA:BBBB:CCCC:0010::210, assuming it is on VLAN 10. So you assign addresses to your boxes, decide if you want static default routes or want to allow them to learn a default via RA, and well, you're basically done for Layer 3. Application level support on Linux/FreeBSD/NetBSD is 98% and rising every day. Apache, BIND, Postfix, they all work great. The "problem" is you may need config adjustment. Your Apache ListenOn's will need IPv6 added, your Postfix "local nets" ACL will need your IPv6 addresses added, and so on. And that is the crux of the migration issue. Updating all the configuration in all the apps to both do the right thing and be secure in IPv6. That is where all of your work will be, particualrly if you have custom systems to manage IP's or configs. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Application level support on Linux/FreeBSD/NetBSD is 98% and rising every day. Apache, BIND, Postfix, they all work great. The "problem" is you may need config adjustment. Your Apache ListenOn's will need IPv6 added, your Postfix "local nets" ACL will need your IPv6
addresses
added, and so on.
And that is the crux of the migration issue. Updating all the configuration in all the apps to both do the right thing and be secure in IPv6. That is where all of your work will be, particualrly if you have custom systems to manage IP's or configs.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
We're still having some problems with linux and java. For example, a v6 socket is supposed to support either protocol. But for some reason, and I don't know if this is just one particular kernel, if communications is attempted under some circumstances with a v4 address on a dual-stacked host, the packets go out on the wire with v6 mapped v4 addresses (::ffff:x.x.x.x) which isn't supposed to happen. So everything isn't quite there yet for dual-stacking all applications. The "safest" approach on paper is v6 native using NAT64/DNS64 but getting the NAT64 piece in place at production quality and scale is a problem at this point.
On Jan 26, 2011, at 11:18 AM, George Bonser wrote:
Application level support on Linux/FreeBSD/NetBSD is 98% and rising every day. Apache, BIND, Postfix, they all work great. The "problem" is you may need config adjustment. Your Apache ListenOn's will need IPv6 added, your Postfix "local nets" ACL will need your IPv6
addresses
added, and so on.
And that is the crux of the migration issue. Updating all the configuration in all the apps to both do the right thing and be secure in IPv6. That is where all of your work will be, particualrly if you have custom systems to manage IP's or configs.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
We're still having some problems with linux and java. For example, a v6 socket is supposed to support either protocol. But for some reason, and I don't know if this is just one particular kernel, if communications is attempted under some circumstances with a v4 address on a dual-stacked host, the packets go out on the wire with v6 mapped v4 addresses (::ffff:x.x.x.x) which isn't supposed to happen. So everything isn't quite there yet for dual-stacking all applications. The "safest" approach on paper is v6 native using NAT64/DNS64 but getting the NAT64 piece in place at production quality and scale is a problem at this point.
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.
Thus spake Leo Bicknell (bicknell@ufp.org) on Wed, Jan 26, 2011 at 10:55:26AM -0800:
The layer 3 part for you is really simple. Here's a deployment model we use a number of places. I'm going to assume you have a /48, from ARIN or your upstream.
Lay out your networks as: AAAA:BBBB:CCCC:<vlan>::/64
The AAAA:BBBB:CCCC::/48 was given to you by ARIN/your upstream. For VLAN I recommend being human friendly and making vlan 10 be AAAA:BBBB:CCCC:0010::/64, even though that's technically 16 in Hex.
At our site, we very strongly discourage mapping like this. Your addressing plan will outlive your infrastructure, and you will be stuck with it until renumbering is no longer hard. Dale
On Wed, 26 Jan 2011, Charles N Wyble wrote:
Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP.
Best to remove IP version dependencies in your configs. If you are using name-based virtual hosting in Apache, convert: Listen a.b.c.d:80 -> Listen 80 <Virtualhost a.b.c.d:80> -> <Virtualhost *:80> Use hard-coded IP addresses only where required for stuff like SSL-enabled webhosts. In postfix just add to main.cf: inet_interfaces = all inet_protocols = all And make sure your MX hostnames have AAAA RRs. Antonio Querubin e-mail/xmpp: tony@lava.net
On Wed, 26 Jan 2011, Antonio Querubin wrote:
Best to remove IP version dependencies in your configs.
If you are using name-based virtual hosting in Apache, convert:
Listen a.b.c.d:80 -> Listen 80 <Virtualhost a.b.c.d:80> -> <Virtualhost *:80>
Use hard-coded IP addresses only where required for stuff like SSL-enabled webhosts.
In postfix just add to main.cf:
inet_interfaces = all inet_protocols = all
And make sure your MX hostnames have AAAA RRs.
One additional note. Add your IPv6 prefixes to mynetworks. The IPv6 prefix should be enclosed in brackets before the prefix length. Ie. the IPv6 loopback would be added as [::1]/128. Antonio Querubin e-mail/xmpp: tony@lava.net
On Jan 26, 2011, at 11:17 AM, Antonio Querubin wrote:
On Wed, 26 Jan 2011, Charles N Wyble wrote:
Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP.
Best to remove IP version dependencies in your configs.
If you are using name-based virtual hosting in Apache, convert:
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. 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.
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 ... YMMV, but, that's working reliably in my environment for: [root@owen conf]# host www.delong.com www.delong.com has address 192.159.10.7 www.delong.com has IPv6 address 2620:0:930::400:7 (The dead:beef:cafe address isn't currently in the AAAAs that are publicly visible because it's used for testing specialized testing from different DNS views.) The machine in question has a number of IPv4 and IPv6 addresses many of which terminate HTTP/HTTPs connections, some of which do not. Owen
On Wed, 26 Jan 2011, Owen DeLong wrote:
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
On Wed, 26 Jan 2011 12:56:01 -1000, Antonio Querubin said:
On Wed, 26 Jan 2011, Owen DeLong wrote:
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.
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. ;)
On Jan 26, 2011, at 3:13 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 26 Jan 2011 12:56:01 -1000, Antonio Querubin said:
On Wed, 26 Jan 2011, Owen DeLong wrote:
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.
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. ;)
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
On Wed, Jan 26, 2011 at 10:22:40AM -0800, Charles N Wyble wrote:
For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard?
Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP.
Depending on your local configuration, you may have to change some minor options (e.g add a IPv6 Listen line for Apache), but yeah, in general it's as simple as adding an AAAA record in the DNS. The only troublesome applications I still encounter these days are Munin (monitoring stuff: http://www.munin-monitoring.org/) and anything that's Java based. If its running on a IPv6-enabled host, Java wants to use IPv6 sockets for everything - including IPv4 connections. Most modern operating systems do not allow this; you have to force the use of either IPv4 or IPv6 and disable the other protocol. I had to put these options in a Tomcat startup script: -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true -- Francois Tigeot
On Jan 26, 2011, at 11:17 AM, Francois Tigeot wrote:
On Wed, Jan 26, 2011 at 10:22:40AM -0800, Charles N Wyble wrote:
For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard?
Do I just need to assign ip addresses to my servers, add AAAA records to my DNS server and that's it? I'm running PowerDNS for DNS, Apache for WWW. Postfix for SMTP.
Depending on your local configuration, you may have to change some minor options (e.g add a IPv6 Listen line for Apache), but yeah, in general it's as simple as adding an AAAA record in the DNS.
The only troublesome applications I still encounter these days are Munin (monitoring stuff: http://www.munin-monitoring.org/) and anything that's Java based.
If its running on a IPv6-enabled host, Java wants to use IPv6 sockets for everything - including IPv4 connections.
If you're not on a broken BSD or Windows implementation, that shouldn't be a problem. It would be nice if BSD would correct their IPV6_V6ONLY behavior instead of putting up an alleged security red herring. I'm not sure why Micr0$0ft suffers from this braindeath.
Most modern operating systems do not allow this; you have to force the use of either IPv4 or IPv6 and disable the other protocol.
Not true. Other than BSD/Windows, most modern operating systems actually follow the RFCs in this regard. Even most of the BSD derivatives will allow you to correctly set IPV6_V6ONLY=False to correct the errant default behavior. Owen
On Wed, 26 Jan 2011, Owen DeLong wrote:
It would be nice if BSD would correct their IPV6_V6ONLY behavior instead of putting up an alleged security red herring. I'm not sure why Micr0$0ft suffers from this braindeath.
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
On Jan 26, 2011, at 2:59 PM, Antonio Querubin wrote:
On Wed, 26 Jan 2011, Owen DeLong wrote:
It would be nice if BSD would correct their IPV6_V6ONLY behavior instead of putting up an alleged security red herring. I'm not sure why Micr0$0ft suffers from this braindeath.
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
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
On Wed, 26 Jan 2011, Owen DeLong wrote:
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. Antonio Querubin e-mail/xmpp: tony@lava.net
On Jan 27, 2011, at 2:53 AM, Antonio Querubin wrote:
On Wed, 26 Jan 2011, Owen DeLong wrote:
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: a: [26.6.5.2] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setu... b: http://www.freebsd.org/cgi/query-pr.cgi?pr=140712
On Wed, 26 Jan 2011 10:22:40 -0800, Charles N Wyble wrote
For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard?
The only issue I've faced is RHEL/CentOS doesn't have stateful connection tracking for IPv6 - so ip6tables is practically worthless. ~Randy
Thus spake Randy McAnally (rsm@fast-serv.com) on Wed, Jan 26, 2011 at 04:50:22PM -0500:
On Wed, 26 Jan 2011 10:22:40 -0800, Charles N Wyble wrote
For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard?
The only issue I've faced is RHEL/CentOS doesn't have stateful connection tracking for IPv6 - so ip6tables is practically worthless.
Yep, we ran into this too early on with rhel [4,5]. Have you looked at rhel 6? Dale
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 01:50 PM, Randy McAnally wrote:
On Wed, 26 Jan 2011 10:22:40 -0800, Charles N Wyble wrote
For the most part, I'm a data center/application administrator/content provider kind of guy. As such, I want to provide all my web content over ipv6, and support ipv6 SMTP. What are folks doing in this regard?
The only issue I've faced is RHEL/CentOS doesn't have stateful connection tracking for IPv6 - so ip6tables is practically worthless.
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQJh0AAoJEMvvG/TyLEAt5pQP/iSi5x43vW5oGGsatcMXCFnz nd4vXZrMlujHazd9DAYwkbwHUXkdXq26sQk+k3Ah90rBecpRJPm6y0O5Gyoktdex oxEP1CRLsgWk1kJFa2aSqS/Lh3loJgXHRaY17sNiqbqWoNXz9meh8oLNATFM5iu0 2uFgxJKQhEGv0iwWUFXtzXkUlQxdFNP71+AcCKY6mhaLYdVUUasmFWrwsumN0KNo WsVhTqI8LLow0HcfOjhxI7QD2m84Hl46oUyIzZ05I2g4iI0BD6UyvrGW2FKEsuml 9Fwb9kULuNBO9vJRPu0PyzgFL6qYtjTC3EigUP8/wpsSDC6TxLLXuZI5cSZnnd8M DOpjhL2854eTNq2IKicaxwb5U+Hq6E4rbpKFZxutvo9z3nFKGOwQx8qUnMiFgNu9 i4oASTus3ZLOkMncacXFxI8CJlvOGlktAeWdDfJ+z1ebCutgtCC1Qkgz7EFGq2oe zejLgMZsKVkr3Ezmiij7CTlrHCiWFeNrl9OLkGs7uB8Kx7SJmJlWRxsU3mfm72np 4Q1MQrk8NSI687S/XI3yf/q0+E73eI7ldYdivstubN5VcPpQDMFOQ/7yYm7AeM7V IbnPwkICxTQqJNALTB3QUFBq5UM26MRONFhi58TAOSkkwgQzyuLarLI4eBft43sx NQ6IrlMG0nFYl1h12SGy =gbrP -----END PGP SIGNATURE-----
On Wed, 26 Jan 2011 13:56:05 -0800, Charles N Wyble wrote
The only issue I've faced is RHEL/CentOS doesn't have stateful connection tracking for IPv6 - so ip6tables is practically worthless.
Hmmmm. Interesting. I wonder if this is specific to the RedHat kernel?
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
On Wednesday, January 26, 2011 05:01:31 pm Randy McAnally wrote:
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.
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....
On Wed, 26 Jan 2011 13:56:05 PST, Charles N Wyble said:
The only issue I've faced is RHEL/CentOS doesn't have stateful connection tracking for IPv6 - so ip6tables is practically worthless.
Hmmmm. Interesting. I wonder if this is specific to the RedHat kernel? Or a problem with v6 support on Linux in general?
(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.
-------- Original Message -------- Subject: Re: Ipv6 for the content provider From: Valdis.Kletnieks@vt.edu To: Charles N Wyble <charles@knownelement.com> Cc: nanog@nanog.org Date: Wednesday, January 26, 2011 4:09:07 PM
On Wed, 26 Jan 2011 13:56:05 PST, Charles N Wyble said:
The only issue I've faced is RHEL/CentOS doesn't have stateful connection tracking for IPv6 - so ip6tables is practically worthless.
Hmmmm. Interesting. I wonder if this is specific to the RedHat kernel? Or a problem with v6 support on Linux in general? (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.
I was under the impression that the later versions of 5 (e.g. 5.5, 5.6) had backported stateful connection tracking. Has anyone tested recently? We mainly use IPtables on end-servers to limit access to a few key applications (like SSH) to trusted subnets, the rest of the applications (SMTP, IMAP, HTTP, etc) are initiated from outside sources so there's no state to being with. In these setups stateful tracking is not a must, but I would still like to have it in case a rogue listener/service is started. We have many RH5 servers deployed, and moving to 6 for this feature alone seems a little much. What I would really like to see is better DoS protection in the form of tracking total number of connections (per host and per application) and new connection rate limits (per host and globally to an application). The last time I tested these features via the optional module, the module was not configurable to the scale we needed nor was it reliable at smaller scales. Perhaps I will test both of these again in RH5 and report back.
On 2011-01-31 12:38, Blake Hudson wrote:
I was under the impression that the later versions of 5 (e.g. 5.5, 5.6) had backported stateful connection tracking. Has anyone tested recently?
The command # ip6tables -A INPUT -m state --state ESTABLISHED -j ACCEPT works on CentOS 5.5. And there's no documentation for it in "man ip6tables". So it fits the backport hypothesis... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca
-------- Original Message -------- Subject: Re: Ipv6 for the content provider From: Simon Perreault <simon.perreault@viagenie.ca> To: nanog@nanog.org Date: Monday, January 31, 2011 11:48:34 AM
On 2011-01-31 12:38, Blake Hudson wrote:
I was under the impression that the later versions of 5 (e.g. 5.5, 5.6) had backported stateful connection tracking. Has anyone tested recently? The command
# ip6tables -A INPUT -m state --state ESTABLISHED -j ACCEPT
works on CentOS 5.5. And there's no documentation for it in "man ip6tables". So it fits the backport hypothesis...
Simon I guess the next question is whether or not it actually works correctly....
On Mon, 31 Jan 2011 11:53:22 -0600, Blake Hudson wrote
# ip6tables -A INPUT -m state --state ESTABLISHED -j ACCEPT
I guess the next question is whether or not it actually works correctly....
You can open/shut ports but you can't do anything with connection state (RELATED, ESTABLISHED, ect). For example, you have to open all upper inbound ports manually if you want to complete outbound connections. The solution is to manually build your own kernel from a vanilla source, along with all the problems that entails. ~Randy
On Monday, January 31, 2011 01:29:18 pm Randy McAnally wrote:
The solution is to manually build your own kernel from a vanilla source, along with all the problems that entails.
There's also the RH eMRG rt kernel which is built on substantially newer sources. You'll need to rebuild it yourself (make an RPM build tree, do rpm -i on the source RPM, rpmbuild -ba on the specfile): ftp://ftp.redhat.com/redhat/linux/enterprise/5Server/en/RHEMRG/SRPMS/kernel-rt-2.6.33.7-rt29.47.el5rt.src.rpm Then you have a kernel that has those newer features and has the integration testing with the other versions of packages installed on the system; using the yum local install, you can get automatic depsolving, too, just in case it has odd dependencies. Or you could get the newer Oracle kernel built for Oracle's RHEL rebuild. Vanilla isn't always best. Sometimes you want chocolate, or butter pecan. Some might joke that RHEL's kernel is rocky road..... and others might call it heavenly hash. Either way, it can be had for CentOS 5 without a whole lot of pain, and in a package system friendly manner.
On Mon, 31 Jan 2011, Simon Perreault wrote:
The command
# ip6tables -A INPUT -m state --state ESTABLISHED -j ACCEPT
works on CentOS 5.5. And there's no documentation for it in "man ip6tables". So it fits the backport hypothesis...
While it may accept it, you may find it doesn't really work the way it should :) I had made the same assumption and discovered various problems. I ended up replacing it with: -A RH-Firewall-1-INPUT -p udp -m udp --dport 32768:61000 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 32768:61000 ! --syn -j ACCEPT which is what ip6tables ships with. You may need to adjust that port range depending on your apps. Antonio Querubin e-mail/xmpp: tony@lava.net
On Wed, 26 Jan 2011, Randy McAnally wrote:
The only issue I've faced is RHEL/CentOS doesn't have stateful connection tracking for IPv6 - so ip6tables is practically worthless.
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
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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
participants (22)
-
Antonio Querubin -
Bill Stewart -
Blake Hudson -
Charles N Wyble -
Dale W. Carder -
David Freedman -
Francois Tigeot -
George B. -
George Bonser -
Graham Beneke -
Jack Bates -
Jack Carrozzo -
Jared Mauch -
Lamar Owen -
Leo Bicknell -
Loránd Jakab -
Mark Andrews -
Owen DeLong -
Randy McAnally -
Simon Perreault -
Tony Esparza -
Valdis.Kletnieks＠vt.edu