In the installations I've helped set up, I've always recommended setting up the 2002::/16 route at the border so as not to depend on upstreams for 6to4 outbound relaying. (The problem is mainly that, for those carriers who do provide a 2002::/16 route, it's usually overloaded, involves roundabout and latent routing, or is somehow just borken. This is the primary reason why so many "native" v6 addresses are simply inaccessible to 6to4.)
Do you have your own 6to4 outbound relay set up, or are you routing those packets through your upstreams?
6to4: native or via upstreams?
Moderator: Moderators
-
- Site Admin
- Posts: 598
- Joined: Wed Nov 17, 2004 10:05 pm
- Location: Nevada
- Contact:
We don't have a 6to4 relay; we're just sending the packets upstream with the rest of it.
Code: Select all
routy-core0#show bgp ipv6 unicast 2002::/16
BGP routing table entry for 2002::/16, version 565193
Paths: (1 available, best #1, table Global-IPv6-Table)
Not advertised to any peer
6175, (received & used)
2620:0:950::242:129 (metric 1) from 2620:0:950::242:129 (208.79.242.129)
Origin IGP, metric 0, localpref 100, valid, internal, best
Technical Support support@rollernet.us
Roller Network LLC
Roller Network LLC
Ah, then I guess "Suggestion Box" is the right place for the question after all.RollerNetSupport wrote:We don't have a 6to4 relay; we're just sending the packets upstream with the rest of it.
Just something to consider adding. Since v4 is still inherently more "well-connected" than v6, doing the 6to4 pseudo-tunnel transition right at the border may make you more accessible to the growing number of v6 islands out there.
Unfortunately, a 6to4 relay only shortens the return path, though that might still be some benefit to some customers such as myself who have their primary mail server residing at a 6to4 address. On the other hand, a teredo relay shortens both directions to the equivalent IPv4 route. When I setup miredo on my own network, it shortened the ping time from my teredo enabled laptop from several hundred milliseconds to about 60ms, the same ping as IPv4 was getting.
Teredo doesn't turn into a direct route. It still uses a relay server to reach hosts on native v6 networks, which may be a different path... unless the remote network also has a Teredo tunnel relay set up, pretty much the same situation as 6to4 noted in this thread. (A Teredo relay isn't the same as a Teredo server; the former does encapsulation/decapsulation, and the latter does address assignment.)sttng359 wrote:Unfortunately, a 6to4 relay only shortens the return path, though that might still be some benefit to some customers such as myself who have their primary mail server residing at a 6to4 address. On the other hand, a teredo relay shortens both directions to the equivalent IPv4 route. When I setup miredo on my own network, it shortened the ping time from my teredo enabled laptop from several hundred milliseconds to about 60ms, the same ping as IPv4 was getting.
I did not say Teredo Server, but Teredo Relay. Teredo attempts to find the closest exit point using IPv6 and sets up a tunnel directly to that relay. A Teredo client uses a Teredo Server only to send an initial bubble which opens a tunnel that will get routed back to the client through the relay closest to the destination creating a symmetrical route. Both sending and receiving use the same relay which, if setup inside the same AS as the destination will probably create a route very similar to what would be used by IPv4 for the same host (assuming their IPv6 network has the same architecture as their IPv4 network). 6to4 uses asymmetrical routing to talk between a native and 6to4 network, the IPv4 anycast address 192.88.99.1 is used to route to the nearest 6to4 relay (according to IPv4) whereas 2002::/48 is used to route to the nearest 6to4 relay (according to IPv6) for the return path. If both the source and destination are 6to4 addresses, then it's smart enough to directly route the packet symmetrically.
Re: 6to4: native or via upstreams?
We've activated a 6to4 relay on one of our border routers.
Seth Mattinen, Roller Network LLC