Project

General

Profile

Feature #2117

6RD support for ISPs like Swisscom

Added by Seth Mos over 7 years ago. Updated almost 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Operating System
Target version:
-
Start date:
01/19/2012
Due date:
% Done:

0%

Estimated time:

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

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

Associated revisions

Revision 0eb78676 (diff)
Added by Seth Mos over 7 years ago

Disable debug statement
Ticket #2117

Revision 32dc8109 (diff)
Added by Seth Mos over 7 years ago

Clarify the UI text with example IPv6 prefix.
Ticket #2117

Revision 1f78ab3a (diff)
Added by Seth Mos over 7 years ago

Make sure we stop the configure if the device does not have a public address
Ticket #2117

Revision 668e8961 (diff)
Added by Seth Mos over 7 years ago

Add backend 6RD support. We don't have the required patch yet for our stf driver.
Needs hooks into our gateway code to handle the default gateway since the stf interface does use router solicitations
Adds to ticket #2117

Revision f87ccbed (diff)
Added by Seth Mos over 7 years ago

Add more backend code to calculate the 6RD broker IPv6 address from the IPv4 broker address.
Adds to ticket #2117

Revision dd576193 (diff)
Added by Seth Mos over 7 years ago

Add code that expresses the default gateway calculated from the broker address.
The stf adapter was correctly setup from the WAN IPv4 address apparently
Adds to ticket #2117

Revision 3f383504 (diff)
Added by Seth Mos over 7 years ago

Add 6rd backend code support, adds rules for proto 41 traffic for 6rd on WAN so that the tunnel works.
Adds to ticket #2117

Revision 12215bfb (diff)
Added by Seth Mos over 7 years ago

Update the interfaces.php for 6rd support, reflects variable changes
Adds to ticket #2117

Revision d500e296 (diff)
Added by Seth Mos over 7 years ago

Adding gateway support for 6rd support, does not add route yet.
Adds to ticket #2117

Revision 556abcab (diff)
Added by Seth Mos over 7 years ago

Adjust the firewall rules for 6rd and 6to4 proto 41 traffic
Ticket #2117

History

#1 Updated by Seth Mos over 7 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

#2 Updated by Seth Mos over 7 years ago

  • Priority changed from Low to High

#3 Updated by Seth Mos over 7 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.

#5 Updated by Seth Mos over 7 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(6): ifconfig stf0
stf0: flags=1<UP> metric 0 mtu 1280
inet6 2a02:125e:d3de:5c0:: prefixlen 28
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

#6 Updated by Seth Mos over 7 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]
  1. configure the srd device
    ifconfig srd0 v4plen 0 pfix 2a02:1200:: plen 28 braddr 193.5.122.254
  2. add a single address for communication
    ifconfig inet6 2a02:1205:25ea:19b0:: prefixlen 128
  3. 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(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(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(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

#8 Updated by Seth Mos over 7 years ago

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.

#9 Updated by Seth Mos over 7 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.

#10 Updated by Seth Mos over 7 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

#11 Updated by Chris Buechler about 7 years ago

  • Target version changed from 8 to 2.1

#12 Updated by Ermal Luçi over 6 years ago

Variable prefix for ipv4 has been committed.
GUI fixes are needed to be done now to allow this to be configured.

#13 Updated by Chris Buechler over 6 years ago

  • Status changed from Feedback to Resolved

#14 Updated by Chris Buechler over 6 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.

#15 Updated by Chris Buechler almost 5 years ago

  • Target version deleted (2.2)

Also available in: Atom PDF