geekmerc (geekmerc) wrote,
geekmerc
geekmerc

IPv6 to the customer

I'll have to write about some of the other things I'm working on, but this is fresh in my mind. In determining the status of deploying IPv6 in our network, I quickly discovered that the edge network will be the most difficult. The first problem I noticed was the limited support by Cisco at this time. Talking to several other vendors, this appears to not be only a Cisco issue. Cisco has considerable support for IPv6 with the PPP technologies. This seems to be the easiest implementation, given that PPP already has support for address handling and radius.

Unfortunately, we primarily use ATM and Vlans in an RBE bridging layout with proxy arp support. Cisco currently recommends assigning a /64 to each interface and using DHCPv6 to give the informational parameters as well as to do Prefix Delegation. There is no support for stateful host addressing (permanent or temporary) via DHCPv6. The primary concern of statically assigning /64 prefixes is privacy. A customer who is not using a router with prefix delegation will always have the same prefix. This would seem to limit the usefulness of privacy extensions which are enabled by default on Windows systems. The second concern is compatibility. I have not seen a home router with IPv6 support yet, but based on the open source solutions I've looked at, mixing stateless autoconfig with prefix delegation doesn't seem to be a preferred method. In addition, Cisco cannot support dynamic host addressing for IPv6 the same way that they handle IPv4. The reason is that there is no support for proxy-nd. I'm not sure proxy-nd would be a good thing. The best method I can think of is to support a dynamic allocation of an address to an interface based on solicitations. This method would work similar to the methods PPP technologies use if they assign a link layer /64.

Here is the basic configuration I deployed for testing IPv6 with a Cisco RBE layout on ATM:

ipv6 unicast-routing
ipv6 cef
ipv6 dhcp pool ipv6pool
 prefix-delegation pool ipv6lpool
 domain-name example.com
!
interface ATM5/0.14250 point-to-point
 ip unnumbered Loopback3
 ip flow ingress
 atm route-bridged ip
 atm route-bridged ipv6
 ipv6 address 2001:XXXX:XXXX:2::1/64
ipv6 enable
 ipv6 mtu 1280
 ipv6 dhcp server ipv6pool
 pvc 14/250
  encapsulation aal5snap
 !
!
ipv6 local pool ipv6lpool 2001:XXXX:XXXX:1000::/52 60

The configuration supports basic IPv4 RBE and assigns 2001:XXXX:XXXX:2::/64 to the customer PVC for autoconfiguration. The domain name as well as prefix delegation are supported on the DHCPv6 server. In this case, it will hand out a /60 from a /52 pool. In production, I suspect we'll hand out /56 or /48 networks in prefix delegation, but my overall testing space at this time is only a /48. It would have been nice if prefix delegation allowed for customers to actually request the number of /64 or the prefix they desired. Unfortunately, either the protocol or the implementations of the protocol do not seem to support this (I'll be honest and admit that I haven't read the protocol yet).

It appears autoconfiguration of 2001:XXX:XXX:2::/64 works fine with my Ubuntu test box as well as Windows XP and Vista. There appears to be a small problem with OpenWRT on a Linksys WRT54GL v1.1. It uses Vlans to separate lan from wan and the stateless autoconfiguration binds the address to the primary ethernet controller and not the vlan. ip -6 neigh shows eth0 router FAILED and eth0.1 router STALE. So functionality wise, it is working, but it isn't as clean as it should be.

I first attempted Prefix Delegation (PD) on the OpenWrt system. Unfortunately, the DHCPv6 client they have for the mips is sorely lacking. Dibbler isn't even available for the mips. This will be something that needs more research. Setting up static routes with IPv6 and manually assigning the interfaces works perfectly fine.

With the Ubuntu system, it took a few tries and some lucky guesses to get things working properly. The first issue was an Ubuntu 8.10 issue. IPv6 is compiled as a module and while it will auto load, it doesn't until after the procps script which processes sysctl commands. First step, had to add ipv6 to /etc/modules. Then I could modify /etc/sysctl.conf and it would work properly. Here's the two important lines:

net.ipv6.conf.all.forwarding=1
net.ipv6.conf.eth0.forwarding=0

The eth0 interface is the "wan" interface. Since enabling forwarding on an interface causes that interface to ignore router announcement messages, I had to explicitly disable it for the one interface. After all, we need to do stateless configuration and generate a default route with the Cisco router. Luckily, we can still forward traffic from and to this interface. The implementation is unpreferred, though. At most, the linux kernel should have automatically changed the default accept_ra value to 0, and let us re-enabled the value on a case by case basis. The status of if an interface can forward traffic should not explicitly prevent it from acting as a host. The ability to send or receive RAs (router advertisements) should be separate from the forwarding status of an interface or globally in the kernel.

That being said, the 2.6.27-9-generic kernel in Ubuntu 8.10 seems to work with the above configuration. I just worry about it breaking later on.

I tried Dibbler as a dhcp client, but it had a few problems. These may be specific to the version that was in the package system or may be a limitation in Dibbler itself. The first problem was that allocation of the received prefix was completely automatic. This didn't allow for setting the local subnet portion or the proper bitmask for each of the interfaces. The second problem was that Dibbler generated a radvd.conf config file which used values not supported by the packaged radvd I installed. Trashed dibbler and tried the other option for Ubuntu 8.10: wide-dhcpv6-client.

wide-dhcpv6-client almost works perfectly. It is like almost completely beautiful; with one problem. You can set an sla-id, but it requires a sla-len. The problem here is that you must first check what size prefix you are getting from your provider and then set the sla-len appropriately. In my case, since I am receiving a /60 and I want /64 on the interfaces, I set sla-len to 4. Hopefully future versions will support giving the length you'd like on the interface and let it calculate the sla-len itself. Computers do know how to subtract as well as they can add. So, with minor changes, I almost used the example file they gave. That's always a good sign. We request domain-name-server and domain-name from the dhcp server as well as send a prefix delegation request on ethernet 0. The received prefix is placed on eth1 and vbox0 (a virtualbox interface is as good as any for testing IPv6).

interface eth0
{

  send ia-pd 0;

  request domain-name-servers;
  request domain-name;

  script "/etc/wide-dhcpv6/dhcp6c-script";
};
id-assoc pd 0 {
        prefix-interface eth1 {
                sla-id 1;
                sla-len 4;
        };
        prefix-interface vbox0 {
                sla-id 2;
                sla-len 4;
        };
};

So far so good. The addresses are assigned to the interfaces as /64 networks:
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:XXXX:XXXX:1011:XXXX:XXXX:XXXX:XXXX/64 scope global
5: vbox0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 500
    inet6 2001:XXXX:XXXX:1012:XXXX:XXXX:XXXX:XXXX/64 scope global

The dhcpv6 client doesn't generate an radvd config file, which is perfectly fine. If we were on BSD with rtdvd, we'd be rocking and rolling. Unfortunately, this is Linux, and radvd isn't up to the same standards as rtdvd. Trial and error is your friend, and sometimes abit of luck.

Here is the /etc/radvd.conf:

interface eth1
{
        AdvSendAdvert on;
        prefix ::/64
        {
                AdvOnLink on;
                AdvRouterAddr on;
                AdvAutonomous on;
        };
};
interface vbox0
{
        AdvSendAdvert on;
        prefix ::/64
        {
                AdvOnLink on;
                AdvRouterAddr on;
                AdvAutonomous on;
        };
};

This will send the router advertisements out the two interfaces. The ::/64 addressing method wasn't found in any documents. It also doesn't work properly. The prefix is sent as the interface's entire address/64. My windows client  It's also possible that multiple addresses on the interface may confuse it. This is the problem with radvd. It supports static configuration just fine, but it seems to have issues dealing with dynamic configurations such as prefix delegations. The method above at least worked with Windows Vista who just ignored everything after the /64 in the advertisement prefix. This is an extreme hack, though. Everything I've read about rtdvd on BSD says it handles the dynamic configuration just fine.

To wrap this up, Cisco seems to have a ways to go with handling IPv6 to customer interfaces. This includes support for NA/TA addressing in DHCPv6, and either proxy-nd or support for dynamically allocated link addressing in RBE/Vlan setups. Current market routers do not support IPv6, and even OpenWRT has limitations with some routers (even the popular WRT54GL). The Linux kernel seems to do okay, though it appears there may be issues with IPv6 and vlan support (based on the issue seen in OpenWRT) as well as issues in handling stateless autoconfig on a linksys router interface (as the method I used while working probably isn't an official setup for performing this task). The radvd code definitely needs some work. While I may have been limited by Ubuntu's version, I suspect the code has problems even in the latest revs based on what I've read in google searches. Finally, more open source dhcp clients should be readily available in distributions and support prefix delegation (and the assignment of those delegations) more appropriately. The customer side of IPv6 has a long ways to go. I haven't even gotten to the testing of end user software and how much of it supports IPv6 (some popular apps support it just fine, while others don't seem to know IPv6 exists), and I haven't covered the serious issues in hardware/software on the public Internet that break IPv6 (#1 issue seen so far is broken DNS load balancers that cause recursive loops when asking for AAAA records).

 

Tags: ipv6, linux, openwrt, ubuntu
Subscribe

  • CentOS 6 usbKey UEFI boot on a Supermicro server

    Some servers, including my Supermicro, don't handle the hybrid ISO on a USB stick very well. That is to say, they won't detect the EFI. Using…

  • Exim 4.72 (EPEL) Ratelimit rules

    Newer version have the ability to count the recipients from an acl_smtp_data block, but this version requires per_rcpt to be set in the…

  • New Project - VM Hell

    So I had to scratch the LAG with SR-IOV plan. I don't need the SR-IOV performance boosts, and the RHEL kernel version is way behind the necessary…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 0 comments