Pim’s reply prompted me to actually read the docs on the web site. LANE reinvented on top of IP. RFC 1925 sect 11 strikes again. Will this bridging madness never stop?
Sorry, couldn’t resist Ivan From: [email protected] [mailto:[email protected]] On Behalf Of Pim van Pelt Sent: Saturday, May 11, 2013 12:27 PM To: Max Tulyev Cc: [email protected] Subject: Re: http://www.6assist.net/ - call for test Hoi, 2013/5/10 Max Tulyev <[email protected]> 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 <[email protected]> PBVP1-RIPE - http://www.ipng.nl/
