IPv6

Good day,

Now that my ALIX board is happily running m0n0wall and I've gotten 6to4 to work, I wanted to ask if there was any thought to adding 6RD (Rapid Deployment) support to m0n0wall?  Comcast is going to be using it as a big part of their upcoming ipv6 trial and my options are to either hope m0n0wall supports it or swap out my ALIX for a Comcast provided box. 

6RD would appear to be a cousin of 6to4 (6RD RFC: http://tools.ietf.org/html/rfc5569) so I'm not sure what would need to be done to add support.  At a minimum, it would seem that I would need to have the ability to set the ipv6 prefix for my ISP. 

I realize I'm probably getting my hopes up a bit early, but I was curious if this was even on anyone's radar?  There are a lot of folks in the Comcast trial forums who are asking about this, so I figured I'd pose the question here.   

AFAIK there is no 6RD support in FreeBSD, so we would have to modify the code used for 6to4 interfaces , the stf interface, to support 6RD.  6RD is so similar to 6to4, that the changes should be small.  However, how the endpoint get's it's prefix and unicast destination from upstream is not clear to me, other than I see there are dhcpv4 options for 6RD

http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd-03#section-7.1.1

Yes, it would seem that there is a DHCPv4 option which passes along the required info, however I imagine it would be advantageous to be able to just enter the information as well. 

The most informative post I've been able to dig up so far on this topic is this one: http://www.dslreports.com/forum/r24121754- 

It appears that we really don't know what Comcast is going to do exactly but this is as good a guess as any I've seen. 

I'm also in the Comcast trials and trying to figure out what I need to do to prepare my home network and WRAP+m0n0wall for IPv6.  Do you know which trial you are in?  I don't know yet.  It would be nice to have a m0n0wall configuration guide for each of the trials.

Linux has support for 6rd, but unfortunately it is based on earlier versions of the pre-specification.  Later on, WAN address compression was added to the pre-spec which allows the ISP to configure the number of leading bits in the WAN IPv4 address to be dropped.  (The v4 WAN address is tacked onto the end of the ISP's 6rd ipv6 prefix; any bits in the v4 WAN address that are site specific are useless since they in no way help identify the WAN client.  Dropping these bits just means more bits for the customer to subnet with)

I did up a perl wrapper for myself that configures a linux 6rd tunnel based on the dynamic dhcpv4 address. I can't test the address compression since the kernel doesn't support it.  Point being, if someone's going to add it to FreeBSD, put that in too so I can switch to FreeBSD   Anyways, the implementation is trivial so I'm sure once freebsd has the 6rd structure in the kernel, patching the tunnel tool will be easy.

DHCPv4 will definitely be the mechanism transferring the isp prefix, prefix length, compression length of the wan address, and 6rd relay server.

One of the really nice things about 6rd is that you can test it without having 6rd support from your ISP.  You can test the machinery out by using the 6to4 prefix and anycast relay... it won't know the difference, since 6to4 is a subset of 6rd.

S.F, Chicago, and Philly are getting Comcast dual-stack trials.  Everyone else is going to be 6rd, since there's no physical restraints to test it.  6rd, dual stack, then CNAT, basically a transition wave: 6rd=v6 over v4, dual stack = v4 and v6, CNAT = v4 over v6.  Then by about the year 2079 we can turn off the last native v4 device.

anyone in a position to test an image ?

anyone in a position to test an image ?

Hi brushedmoss,

Sorry we spaced out for a while.  We will be trying the PD stuff, and if you have some 6rd stuff we can give that a shot this week as well. 

Does your image do the ipv4 address compression?  We haven't had a chance to test a CPE with that yet.

My plan is to do a dhcp request for option_6rd

and from that use IPv4MaskLen, 6rdBRIPv4Address , 6rdPrefixLen and 6rdPrefix

and then use that to run the equivalent of

Code:

/sbin/ifconfig stf0 create
/sbin/ifconfig stf0 inet6 (6rdPrefix + (wan ipv4 minus the high order bits from IPv4MaskLen))  prefixlen (6rdPrefixLen) alias
/sbin/route delete -inet6 default'

/sbin/route add -inet6 default (6rdPrefix + 6rdBRIPv4Address)

Hi brushedmoss -

I should be able to test out a 6rd image (PC) if you have one. Let me know what's available and I'll give it a try.

-Matt

great ! are you on the comcast trial ?

I take a look at this during the week.

Hi brushedmoss -

I personally am not part of the Comcast trial, but my colleague (digitalsushi) is. We are also working on a 6rd project internally and have an environment to test it.

-Matt

Sorry, I also got pulled off into the real world due to work and whatnot.  I just wanted to post that at least for the Comcast run of 6RD there is some more info.  It looks like they provided Openwrt images for a Linksys router and more helpfully for this group I think is that they provided the settings they're using. 

http://www.comcast6.net/6rd-config.php

That is very odd, they are using dhcp option 150

Since IANA has yet allocated the DCHP option number for 6RD, we use 150, which will work fine until the reserved option number has been assigned by IANA.

yet, 150 is a well established option for TFTP server, and 212 is for 6RD

http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml

and their source uses both

Code:

cat dhclient4-nom.conf
option  dhcp.6rdinfo code 212 = string;

Code:

cat dhclient4-stat.conf
option  dhcp.6rdprefix code 150 = string;
option  dhcp.6rdbr code 151 = ip-address;

The DHCP didn't appear to work for me; I had to enter the configuration values into a static tunnel configuration.  I'm guessing m0n0wall doesn't yet have this functionality as I see the call for testing for the FreeBSD 6rd patch just went out not that long ago. 

I just started to look at this today, to see what I can do with the existing dhclient.

Do you have a tcpdump of your dhcp requests , raw packets would be good.  And did you try options 150, 151 and 212 ?