Powered byContact us:
E-mail: maxtul@netassist.ua
Jabber: mt6561@jabber.kiev.ua

Abstract

The IPv6 implementation in networks can't be connected to IPv6 Internet native, require a tunnel-based connectivity. There are a number of Tunnel Brokers providing IPv6 connectivity over IPv4 tunnels. The main disadvantage of using a tunnel broker is traffic path not optimal. Imagine you are in Germany, use the IPv6 tunnel broker in USA and connecting via IPv6 to some server in Italy:

As you can see, traffic from Europe to Europe travels through USA. The second issue is all the traffic is hubbed at the tunnel server, so if one customer is downloading some huge file - the rest of the people connected to the tunnel broker server can only share the tiny rest of the tunnel server bandwidth... This all lead to the great performance loss in this tunnelled IPv6 connection in comparsion with native IPv4 connection between same points. The 6assist initiative solves this. IPv6 traffic between 6assist clients flows directly to each other, by the same route as it is with IPv4:

Virtual Ethernet: MPTP

We are developing the fast point-to-multipoint tunnel software based on own MultiPoint Tunnel Protocol (MPTP). In fact now, this is a virtual Ethernet based on Linux TUN/TAP driver. The main idea of dealing with this virtual Ethernet packets is MAC addresses of each participants is mapped to unique IPv4 address. When MPTP daemon deals with incoming IP packet, it takes the destination MAC address, exctracts the destination IPv4 address from it, encapsulates it into IPv4 UDP packet and sends to the destination. The recieving side reconstructs the destination MAC from the IPv4 destination address, source MAC from IPv4 source address and releases it into the TAP interface. As the MACs inside the MPTP Ethernet are fast and clearly mapped to IPv4 MPTP peers, there is no need in any central node for forwarding the regular traffic, as it is flowing directly between peers.

How peers find each other? In Ethernet there are broadcast packets. To let them work, there is a special node called MPTP Hub. It collects broadcast packets and redistributes it to all nodes connected. Each node connects to MPTP Hub upon startup and maintain this connection all the time. MPTP Hub is used only to find peers in Ethernet (like for ARP protocol), but not used for forwarding the real traffic betweed nodes:

IPv6-On-Top IXP

So we have a virtual Ethernet with direct communication between nodes. What's next? Let's start it using as the base for "regular" IPv6 Internet Exchange! We set up a route server inside this virtual Ethernet to maintain connectivity between participants, but direct peering is also possible. We are going to maintain the unique Autonomous System for this as well.

Requirements for participants

First of all, please consider this initiative is in deep developping and testing right now! Do not mean it is stable - it is NOT! I will update this site again when we will be in considered stable status ;)

To participate, you have to have:

  • Own Internet autonomous system;
  • Own IPv6 network /48 or more;
  • Knowlege in BGP setting up and maintaining, as well as in Linux routing;
  • Linux or FreeBSD software router with TUN/TAP driver compiled in or as the module.

    Setting things up

    First, set up Linux (FreeBSD) router as BGP router under your ASN. You can use for that bird, quagga or similar software you like. Then connect it to your IPv6 network core with BGP. Now you are ready to set up the MPTP software. Download it, unpack with "tar xvfJ 6assist.tar.xz", then compile with "make". You will got two files: mptp and mptp-hub. Second is necessary only if you build your own fully independent MPTP infrastructure. Run "mptp your_ip 195.214.214.195". Your_ip is your IPv4 address will be used to communicate with other peers, usually main IP address of your Linux MPTP router. 195.214.214.195 is our MPTP hub. MPTP uses UDP/55555 port to communicate between peers and TCP/55555 to connect to MPTP hub. These ports should not be filtered.

    If everything went fine, you will have a tap0 (or first free TAP, if there was any) interface. Now you are ready to configure IPv6 BGP session with the route-server. Route-server have the IP address 2001:67c:1728::1 and AS number 60817. The interface IP addresses of all peers are 2001:67c:1728::XXXX/64, where XXXX is the AS number in hex. For example, 2001:67c:1728::73c0/64 is the interface address of peer with ASN 29632. Configure the correct IP address on your side (ask us if in doubt), check 2001:67c:1728::1 pings good, and contact us (details are on top of the page), tell your ASN, list of IPv6 prefixes, and wait us configure our side. Then enjoy your best IPv6 tunnelled connectivity can ever be! ;)

    Next steps in development

    As I said, this is a just a kind of concept now. There is a lot of job in front of us. Hers is some milestones:

  • Testing!!! ;) This will be forever!
  • Security. It is none, so everyone can join and everyone can sent a (spoofed) packet to the MPTP virtual Ethernet. We developping the secure authorization of client at MPTP Hub, as well as packet signing to be sure packets came from really right place. By the ideology, we decided NOT to use any cryptography in MPTP traffic, but authorization at MPTP Hub and in each packet sure to be a must. Own DoS protection should be useful too.
  • Speed UP. The current solution is pretty fast, but in-kernel driver sure will be faster.
  • As the MPTP Hub is week place, there should be a way to back-up it. Or have several ones. Or have a distributed peer table like in P2P networks. It is still under negotiations.
  • Advertisement, of course!

    If you want to join our team, or have any questions, ideas, comments, feedbacks - do not hestiate to contact us! The contact information is on top of this page! ;)