Feature #2117
open6RD support for ISPs like Swisscom
Added by Seth Mos over 12 years ago. Updated about 10 years ago.
0%
Description
databeestje_: 3. Select “6RD” as tunnel protocol, and configure its parameters:
[22:02] databeestje_: 1. IPv4 address of the tunnel end-point: 6rd.swisscom.com (193.5.122.254)
[22:02] databeestje_: 2. IPv6 prefix: 2a02:1200:: / 28
[22:02] databeestje_: 3. Optional: Set MTU manually to 1480 Bytes
http://lists.freebsd.org/pipermail/freebsd-net/2010-September/026589.html
[22:10] databeestje_: http://research.sakura.ad.jp/6rd-trial/6rd-trial-freebsd8/
[22:10] databeestje_: http://www.mail-archive.com/freebsd-net@freebsd.org/msg34420.html
Files
firewall traffic pass srd0.PNG (3.33 KB) firewall traffic pass srd0.PNG | Seth Mos, 02/21/2012 03:11 AM | ||
6rd-2.pcap (460 Bytes) 6rd-2.pcap | host 6rd relay | Seth Mos, 04/01/2012 01:47 PM | |
6rd.pcap (790 Bytes) 6rd.pcap | proto 41 traffic | Seth Mos, 04/01/2012 01:47 PM |
Updated by Seth Mos over 12 years ago
Got a reply from Swisscom clarifying their 6RD deployment, past trial, now production.
Our productive network uses 6rd, the trial phase is finished. The firmware with IPv6/6rd support is currently rolled out to about 500'000 customer routers, which is almost a third of our customer base. Free.fr has twice that number of customers, and other ISPs such as Softbank in Japan or Fastweb in Italy are also using 6rd. We will not implement DHCP-PD on the current generation of our network. Once all users are migrated to the next generation of networks we will reconsider this situation, but that won't happen before 2015.
So, yes, we need to add a 6RD stf adapter iirc. Or port and fix one of the existing patches.
Forum post.
http://forum.pfsense.org/index.php/topic,45102.0.html
Updated by Seth Mos over 12 years ago
- Priority changed from High to Normal
A healthy chunk of code is already in there. Come to think of it, 6to4 is very similar to this, but the patch for stf isn't applying against 9.
I've emailed hrs@ but that might take a while.
I might be able to work 6to4 support in, but that takes extra time and the IETF deprecated support for 6to4.
The largest difference between the 2 is that 6RD tunnels are terminated on ISP equipment and are thus a lot faster and reliable then tunneling across the world to the 1st anycasted relay.
Updated by Seth Mos over 12 years ago
earlier 6rd work. http://bougaidenpa.org/masakazu/archives/54
Updated by Seth Mos over 12 years ago
from reading the sparse documentation one needs to calculate the IPv6 prefix address for the broker inside the give prefix.
so with a prefix of 2a02:1200:: / 28 that would add up to the following prefix.
Broker IPv4
193 5 122 254
2a02:12<193>:<5><122>:<254>0::/28
route add -inet6 default 2a02:12c1:57a:fe0:0:0:0:1
Local stf0 prefix based on the WAN IPv4
2a02:125e:d3de:5c0::/28
This would assign a /60 to each user where they can pick a network from the last 16 bits of the number iirc. Need to verify with Swisscom if the calculus is right.
[2.1-DEVELOPMENT][root@leaf.dnsalias.org]/root(6): ifconfig stf0
stf0: flags=1<UP> metric 0 mtu 1280
inet6 2a02:125e:d3de:5c0:: prefixlen 28
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
Updated by Seth Mos over 12 years ago
Ok, further testing reveals we need RFC 5969 6rd standards track. That means support for differing IPv4 prefix lengths which only the patch from Masakazu-san does.
The FreeBSD 8.3 builds are now built with this patch and rudimentary testing reveals the incoming path works.
[code]- configure the srd device
ifconfig srd0 v4plen 0 pfix 2a02:1200:: plen 28 braddr 193.5.122.254 - add a single address for communication
ifconfig inet6 2a02:1205:25ea:19b0:: prefixlen 128 - ifconfig srd0
srd0: flags=1<UP> metric 0 mtu 1280
inet6 2a02:1205:25ea:19b0:: prefixlen 128
nd6 options=8043<PERFORMNUD,ACCEPT_RTADV,DEFAULTIF>
srd: v4plen 0 pfix 2a02:1200:: plen 28 braddr 193.5.122.254
[/code]
Send a ping from the IPv6 internet to the configure inet6 on srd0.
[code]
seth@ratchet:~$ ping6 -c1 2a02:1205:25ea:19b0::
PING 2a02:1205:25ea:19b0::(2a02:1205:25ea:19b0::) 56 data bytes
--- 2a02:1205:25ea:19b0:: ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
[/code]
This show incoming traffic from the 6rd broker relay on the doorstep.
[code]
[2.1-DEVELOPMENT][root@pfsense.localdomain]/root(12): tcpdump -nvei em0 host 193.5.122.254
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
11:26:51.901986 00:d0:ff:f8:ac:00 > 00:50:56:83:00:0b, ethertype IPv4 (0x0800), length 138: (tos 0x0, ttl 248, id 37098, offset 0, flags [none], proto IPv6 (41), length 124)
193.5.122.254 > 82.94.161.155: (hlim 56, next-header ICMPv6 (58) payload length: 64) 2001:67c:226c:e065::1:1 > 2a02:1205:25ea:19b0::: ICMP6, echo request, length 64, seq 1
^C
1 packets captured
[/code]
The ping6 packet is succesfully logged in the pfSense UI as I had a rule for logging all IPv6 traffic on this box.
The problem here is that it is not possible to reach the IPv6 internet because setting the gateway does not currently work.
[code]
[2.1-DEVELOPMENT][root@pfsense.localdomain]/root(19): route add -inet6 default ::1 -ifp srd0
add net default: gateway ::1
[/code]
This command does take and it show in the routing table.
[code]
Internet6:
Destination Gateway Flags Netif Expire
default ::1 UGS srd0
::1 ::1 UH lo0
[/code]
But I can't get anything out onto the internet with it.
[code]
[2.1-DEVELOPMENT][root@pfsense.localdomain]/root(13): ping6 ipv6.google.com
PING6 2a02:1205:25ea:19b0:: --> 2a00:1450:400c:c01::67
ping6: sendmsg: Network is unreachable
ping6: wrote ipv6.l.google.com 16 chars, ret=-1
^C
--- ipv6.l.google.com ping6 statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
[/code]
Complete log
http://www.pastie.org/private/j6ufhloh2kqesznee6y8na
Updated by Seth Mos over 12 years ago
Updated by Seth Mos over 12 years ago
- File 6rd-2.pcap 6rd-2.pcap added
- File 6rd.pcap 6rd.pcap added
Ok, I've switched the tree back to the modified stf device which does receive IPv6 packets by proto 41 and can also send packets by IP proto 41.
However, 2 way comms still does not work. No replies inbound, no replies outbound.
2 packet captures. 1 for proto 41 traffic in general. Another against the 6rd host.
Updated by Seth Mos over 12 years ago
- Status changed from New to Feedback
More debugging revealed the following, SwissCom and ATT do not filter inbound IPv6 traffic for IPv4 space they do not own.
So inbound always works, but the reply traffic is dropped by SwissCom and ATT.
However, not all is lost, because Charter and Sakura do not filter their 6rd relay traffic at all.
Charter is http://www.myaccount.charter.com/customers/Support.aspx?SupportArticleID=2665#ipv6prep
2602:100::/32 -> 68.114.165.1
16 bytes from 2a00:1450:400c:c01::63, icmp_seq=0 hlim=51 time=215.957 ms
Sakura is http://research.sakura.ad.jp/6rd-trial/
2001:e41::/32 -> 61.211.224.125
16 bytes from 2a00:1450:400c:c01::63, icmp_seq=0 hlim=50 time=507.456 ms
That should suffice for basic testing.
Updated by Seth Mos over 12 years ago
Add a Enable 6rd checkbox on the 6rd or DHCP4 settings to automatically configure 6rd from DHCP option 212.
http://forum.pfsense.org/index.php/topic,48116.msg255523.html#msg255523
Updated by Chris Buechler over 12 years ago
- Target version changed from 8 to 2.1
Updated by Ermal Luçi over 11 years ago
Variable prefix for ipv4 has been committed.
GUI fixes are needed to be done now to allow this to be configured.
Updated by Chris Buechler over 11 years ago
- Status changed from Feedback to Resolved
Updated by Chris Buechler over 11 years ago
- Status changed from Resolved to New
- Target version changed from 2.1 to 2.2
this wasn't for 6rd in general as I thought, rather a diff type.