IPv6 6RD testing

[dane]

It's also worth noting that IPv6 is a bigger address space than IPv4, resulting in more overhead in the header. So at a given sync speed, IPv6 payload throughput will be lower than IPv4.

Makes me wonder why so many of you are excited about IPv6.

[Guest]

It's also worth noting that IPv6 is a bigger address space than IPv4, resulting in more overhead in the header. So at a given sync speed, IPv6 payload throughput will be lower than IPv4.

Makes me wonder why so many of you are excited about IPv6. ;)

All we have to do is send more packets (in fact, IPv6 DNS packets for the DNS root servers have to be fragmented UDP).

There are three reasons:
1.AT&T and Comcast shouldn't be having something (6rd) that Sonic doesn't (right?).
2.With IPv4 being something to conserve, IPv6 could provide a solution for things like remote access and the Internet of Things, otherwise people might use multiple IPv4s instead.
3.Since I can't do the 6in4 tunnel (don't want to use bridge mode of modem), I currently rely on a rather unreliable UDP tunnel with less-than-optimal latency.

[davidstrauss]

What is the status of 6rd early access and full deployment for Business Ethernet customers?

[tomoc]

What is the status of 6rd early access and full deployment for Business Ethernet customers?

IPv6 support for FlexLink and fiber products is assessed on a per customer basis. If you are interested in enabling IPv6 on your enterprise service, contact network operations and we will determine if your circuit is currently eligible.

[danagoyette]

I've gotten the tunnel to work on AdvancedTomato, which lacks a formal 6rd option.

Notably, I had to combine a couple of resources. I give credit to the the calculator tool linked on the first page, for showing me what values to expect, and for the following page for showing how to get the _correct_ ipv6 address division:

http://www.dslreports.com/forum/remark,28220947 -- in essence, you merely replace "2602:30" with "2602:24", and the v4 gateway with Sonic's v4 gateway.

Here's the portion of my 'firewall' script (since wan-up never seems to run):

Code: Select all

insmod v4tunnel
insmod sit 

WANIP=$(nvram get wan_ipaddr)

if [ -n "$WANIP" ]; then
  ip tunnel del tun6rd

  #WRONG:
  #V6PREFIX=$(printf '2602:%02x:%02x%02x:%02x00' $(echo $WANIP | tr . ' '))

  #CORRECT:
  V6PREFIX="$(printf '%02x%02x%02x%02x' $(echo $WANIP | tr . ' ') | awk '{print "2602:24" substr($1,1,1) ":" substr($1,2,4) ":" substr($1,6) "0"}')"

  ip tunnel add tun6rd mode sit local $WANIP ttl 64
  ip addr add ${V6PREFIX}::1/28 dev tun6rd
  ip addr add ${V6PREFIX}::1/64 dev br0
  ip addr add ::$WANIP/128 dev tun6rd
  ip link set tun6rd mtu 1472 # not certain if this is actually needed
  ip link set tun6rd up
  ip -6 route add ::/0 via ::184.23.144.1 dev tun6rd
fi

EDIT: Argh, it works until the WAN IP renews... then dies. The wan_up script is definitely not running, or the IP would be re-created.

EDIT again: I gave up on AdvancedTomato, and switched to the regular Shibby builds. No reset was needed, because AdvancedTomato is merely a UI change. Now I no longer even need the script -- the GUI has formal configuration options for it. However, I did have to configure it with prefix '32' instead of '28', and then ssh to run:

Code: Select all

nvram set ipv6_6rd_prefix_length=28
nvram commit

[nwhitehorn]

Is there a reason to use traditional IPv6 tunnels vs. 6RD? Are the older tunnels going away? Is one expected to have better performance or peering?

[Guest]

Is there a reason to use traditional IPv6 tunnels vs. 6RD? Are the older tunnels going away? Is one expected to have better performance or peering?

6rd is more reliable than 6in4, and is much easier to set up automatically.

[nwhitehorn]

Is it more reliable because it is supposed to be more production-grade at Sonic's end? The protocol is identical -- 6RD is just an automatic setup scheme for 6in4 tunnels.

[Guest]

Is it more reliable because it is supposed to be more production-grade at Sonic's end? The protocol is identical -- 6RD is just an automatic setup scheme for 6in4 tunnels.

Actually, that isn't true.

6rd has a lot more in common with 6to4 than 6in4.

As for reliability, it'll mostly be on Sonic's side.

[nwhitehorn]

That's partially true. 6to4 is also just 6in4, but with an anycast remote end and a well-known automatic addressing scheme that any IPv4 host can use. From the client (though not the router) side, both of these features are gone in 6RD and so it just looks like a regular tunnel. For example, you can establish 6RD connectivity even without explicit OS support by establishing a tunnel to the 6RD endpoint from the first post with the addresses given.

Anyway, it doesn't seem like there's any real difference so I think I'll stick with the tunnel for now. Thanks!