http://www.6assist.net/ - call for test
Pim van Pelt
pim at ipng.nl
Sat May 11 12:27:04 CEST 2013
Hoi,
2013/5/10 Max Tulyev <maxtul at netassist.kiev.ua>
> The website of that project is http://www.6assist.net/
> It acts like a virtual media IXP, and anybody have own ASN can join it.
>
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.
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.
- does it support (ethernet / IP) multicast (v4 and/or v6?)
- 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.
- I understand that the hub will provide authentication - what is the
design for this authentication mechanism?
- 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?
Good luck with your project! And please, pretty please, do not recreate the
3ffe::/16 mess!
--
Pim van Pelt <pim at ipng.nl>
PBVP1-RIPE - http://www.ipng.nl/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130511/c4c186da/attachment.htm>
More information about the ipv6-ops
mailing list