[TriLUG] IPv6 workshop

Jonathan Woodbury jpwoodbu at mybox.org
Sat Apr 16 02:37:17 EDT 2011


Hey Greg,

I'm happy to help you with your homework!  Before I do, let's talk
about your transition options.  IMO, there's really only two if you
want decent performance.

SIT (Simple Internet Transition) tunnel to an outfit like Hurricane Electric:
    * static IPv6 addressing
    * predictable latency in both directions
    * easy to maintain, especially if you want reverse DNS delegation

6to4 tunnel:
    * doesn't require a tunnel broker
    * identical routing when compared with IPv4 to other 6to4 networks
(i.e. it's fast to other 6to4 networks)
    * unpredictable and often poor performance to the rest of the IPv6 Internet
    * A pain to maintain if your IPv4 address changes
        * dynamic IPv4 address = dynamic IPv6 prefix
        * dynamic IPv6 prefix = lots of potential DNS maintenance

I used to favor 6to4 tunnels when what I was mostly doing with them
was connecting two IPv4 networks together with something that felt
like a site-to-site tunnel.  Which is pretty much what it was, but
with the added benefit of being globally reachable. But traffic from
other IPv6 networks was really sluggish and maintaining DNS, both
forward and reverse zones, was really painful whenever my IPv4 address
changed from my ISP.  And if I tried to reach my 6to4 network with a
teredo tunnel, the performance was often so bad it was not usable.

The HE tunnels were too slow when I first tried them as they didn't
have a tunnel endpoint nearby.  But now they have one in VA that I
usually can ping at 20ms.  I've converted all my IPv6 networks to
using HE tunnels and I've been happier ever since.  If my IPv4 address
changes at home, I just update the tunnel configuration and I'm back
in business.  HE's network is so good for me that I don't even notice
if I'm using a site over IPv6 or IPv4.  To the extent that you're tied
to HE, you are using their address space to get real IPv6 addresses.
They are just using SIT tunnels (feels a lot like GRE), so there's no
weird software you have to run.  So if you decided to switch to
another broker that offered SIT tunnel brokering, your tunnel
configuration would change very little, but you'd have to use all new
IPv6 addresses, which is a far more painful change.

Now on to your home work...  If you're using Linux as your router, you
might have to change your feelings on NAT with IPv6.  The kernels I've
been using do not have a NAT table for ip6tables.   AFAIK, it's
technically possible to perform NAT operations with IPv6, but it's
generally discouraged and it seems the Linux kernel team might be in
strong agreement on that.  I can say from my own personal experience
that not having NAT statements makes my firewall config seem that much
simpler.  I like that I can just look at my FORWARD chain to get "the
whole story" on what IPv6 traffic is allowed through my firewall.

I'm going to talk this through in the context of using a HE tunnel,
since they're my personal preference.  Every IPv6 network is a /64
network and you have multiple networks in your config, so you'll want
to ask HE to deliver a /48 to you.  You'll be able to make up to 2^16
/64 networks with that!  The IPv6 addressing on your gateway's tunnel
interface will be on a /64 network outside of your /48.  This is a
very important point.  Most people I've helped set this up don't often
realize that the routing network HE gives them is completely separate
from the IPv6 networks being routed to them.  I myself misunderstood
that at first.

This is the actual example config that the http://tunnelbroker.net
site spits out for one of my networks using Linux iproute2 (except
that I did hide some addressing with x's for good measure):

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.22.2 local xxx.xxx.xxx.xxx ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:7:xxxx::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

That snippet just sets up my tunnel interface, but the actual network
they've allocated to me is 2001:470:8:xxxx/64.  But if I asked HE to
route to me a /48, the network would probably read 2001:470:8/48.
This tunnel interface should be thought of as your edge IPv6 network.
So now to configure your 3 internal network interfaces:

DMZ (perhaps eth1.10)
ip address add 2001:470:8:1::1/64 dev eth1.10

Week wireless network (perhaps eth1.20)
ip address add 2001:470:8:2::1/64 dev eth1.20

Desktop network (perhaps eth1.30)
ip address add 2001:470:8:3::1/64 dev eth1.30

So now you've got real IPv6 addresses on all your gateway interfaces,
and maybe you've already made sure that
/proc/sys/net/ipv6/conf/all/forwarding is 1 and that you've got
whatever ip6tables FORWARD chain rules setup to your liking.  But the
other hosts on those networks still don't have IPv6 global addresses.
I believe the simplest way to get those setup is to use StateLess
Automatic Address Configuration (SLAAC).  Most modern OSes will work
with this right out of the box.  The way this works is that your
router advertises itself on one or more of your networks.  In that
advertisement is the network prefix for that network.  Devices on that
network can use their MAC address in combination with that prefix to
automatically configure a real global IPv6 address for themselves.
And, of course, they can also configure a default gateway using the
address of the advertised router.  I use a program called radvd on my
router for this.  Here's a config that fits our example above:

interface eth1.10
{
    MinRtrAdvInterval 3;
    MaxRtrAdvInterval 10;
    AdvLinkMTU 1280;
    AdvSendAdvert on;
    AdvOtherConfigFlag on;
    prefix 2001:470:8:1::/64
    {
        AdvOnLink on;
        AdvAutonomous on;
        AdvValidLifetime 86400;
        AdvPreferredLifetime 3600;
        AdvRouterAddr on;
    };
};

interface eth1.20
{
    MinRtrAdvInterval 3;
    MaxRtrAdvInterval 10;
    AdvLinkMTU 1280;
    AdvSendAdvert on;
    AdvOtherConfigFlag on;
    prefix 2001:470:8:2::/64
    {
        AdvOnLink on;
        AdvAutonomous on;
        AdvValidLifetime 86400;
        AdvPreferredLifetime 3600;
        AdvRouterAddr on;
    };
};

interface eth1.30
{
    MinRtrAdvInterval 3;
    MaxRtrAdvInterval 10;
    AdvLinkMTU 1280;
    AdvSendAdvert on;
    AdvOtherConfigFlag on;
    prefix 2001:470:8:3::/64
    {
        AdvOnLink on;
        AdvAutonomous on;
        AdvValidLifetime 86400;
        AdvPreferredLifetime 3600;
        AdvRouterAddr on;
    };
};

Once radvd is running with a config like that, almost immediately, all
your devices will have real IPv6 addresses!  A good test is to try to
visit http://ipv6.he.net.  They'll print your IPv6 address on the
page, or your IPv4 address if that's how you ended up reaching them.

Since you have networks that are private islands, a basic ip6tables
FORWARD chain might start like this:
ip6tables -P FORWARD DROP
ip6tables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i eth1.20 -j ACCEPT -m comment --comment
"forward inbound traffic from week wireless network"
ip6tables -A FORWARD -i eth1.30 -j ACCEPT -m comment --comment
"forward inbound traffic from desktop network"

That's pretty simple and should behave a lot like a IPv4 dynamic NAT
firewall in terms of traffic flow.

It's pretty late now, and I didn't expect to write this much.  If
you're still with me, thanks!  I'm sorry in advance for the inevitable
typos and conceptual mistakes I likely made due to the late hour.  I
hope this helps!

Jonathan

On Fri, Apr 15, 2011 at 10:43 PM, Kevin Otte <nivex at nivex.net> wrote:
> On 04/15/2011 07:38 PM, Greg Cox wrote:
>
>> If only there were this non-real-time collaborative tool... like a list
>> that mail can go to....
>
> The problem is that non-real-time. When I gave my presentation in
> August, the "homework assignment" I gave out was to go home and set up a
> tunnel to start experimenting. At the next month's meeting, I asked
> everyone who had done so to raise their hand. Not a single one went up.
>
> This thread is evidence that there is interest, but time is a scarce
> commodity. By allocating a time and saying "I'm going to sit down and do
> this" along with some peers, you ensure that it will happen.
>
>> Now, I fully admit this is not as sexy as fully embracing that whole
>> openness thing.
>
> I certainly didn't get into networking to get laid. Not once have I
> walked up to a woman and said "I know IPv6" and had her jump all over
> me. (Yes, I abhor the overuse of "sexy" as a marketing term. Can you tell?)
>
> But seriously, you are absolutely right. This is inglorious work. Those
> of us who actually like to geek out on this stuff are pretty rare. The
> rest of the world has come to expect the Internet to Just Work™
> Figuring out how to make it all work so the rest don't even notice is
> the crux of the problem.
>
> To address the openness issue (as well as the other issues you've
> raised) head on, I highly recommend you watch this LinuxConf AU keynote
> by Geoff Huston.
>
> http://linuxconfau.blip.tv/file/4692762/
>
>> I'm getting tired of v6 talk
>
> Less talk, more action would be great.  Hence the workshop.
>
>> when I see little in transition plans that work with the reality that
>> (a) services beside ping still exist
>
> Reality is a fluid thing, which is why the original transition plan (you
> know: actually get IPv6 deployed *before* we ran out of IPv4 addresses)
> isn't the one we're on now.
>
> As for services besides ping: Google is IPv6 enabled. Facebook is IPv6
> enabled. There are plenty of others.
>
>> ...
>
> I thank you for bringing up these questions. Making sure all of these
> issues get addressed is vitally important, even if it does mean things
> take a little longer. Keep at it; we'll get there :)
>
> -- Kevin
> --
> This message was sent to: Jonathan Woodbury <jpwoodbu at mybox.org>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that address.
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web  : http://www.trilug.org/mailman/options/trilug/jpwoodbu%40mybox.org
> TriLUG FAQ          : http://www.trilug.org/wiki/Frequently_Asked_Questions
>



More information about the TriLUG mailing list