http://www.6assist.net/ - call for test

[Max Tulyev]

Hi!

On 11.05.13 13:27, Pim van Pelt wrote:
> As others pointed out, I do not really see the problem you are solving
> [well, I see it, but I do not agree that the problem exists]. If you
> look at the larger more established tunnelbrokers, they will invariably
> all have multiple points of presence, HE / SixXS as two examples. Here,
> the ISP takes care of the IPv6 network, and the IPv4 endpoint is
> topologically close. But, I will agree that some localities do not have
> any reasonable coverage, and in those cases, MPTP may help.

If you can't see the problem from one point of view from one point of
globe - it doesn't mean it didn't really exist in another ;)

> Some questions:
> - does this infrastructure bridge ethernet  to IP (that's what I believe
> from your website)? I ask because somebody may be interested to use this
> for IPv4 as well.

Yes.

> - does it support (ethernet / IP) multicast (v4 and/or v6?)

Yes, but threads it as broadcast.

It is not about particular IP protocol like IPv4/IPv6, but about general
Ethernet, so even IPX will work.

> - does it use compression? If it doesn't, then what is your 'shared
> segment' MTU? Does that work well for you? Note: if you use header
> compression you can probably easily retrieve the wasted bytes in
> protocol overhead, and still provide a 1500b MTU.

No. In fact, it might be useful in some places, so may be it is a good
idea to implement for example LZO. But compression is not about MTU at
all. You can't guarantee EVERY packet will be compressed to fit is
certain smaller packet.

So, decreasing of MTU is a real disadvantage of ANY tunneling
environment. You should live with it.

> - I understand that the hub will provide authentication - what is the
> design for this authentication mechanism?

None yet. It will be realized if people will consider the whole idea
good to be developped further.

> - What happens if the hub goes away? Do the clients cache the IPv4
> endpoints of their peers, in other words, is transient failure of the
> hub impacting anything?

Broadcasts don't work, everything else will. For example, if you
established ARP already, traffic will continue to flow.

In current implementation, by trying to send every broadcast packet, it
will be try to reconnect to the hub.