Re: [6bed4-devel] Comments and thoughts on bed64
zeroconfig IPv6 tunnel
Status: Beta
Brought to you by:
vanrein
From: <ebi...@xm...> - 2012-07-12 11:01:05
|
Rick van Rein <ri...@op...> writes: > Hello Eric, > > Thanks again for your feedback. You've been so productive that I had > to allocate some serious time, causing the delay in the response. > > You picked up that the name is not bed64 but 6bed4, right? Yes. I'm not certain why I wrote bed64 in the initial subject line. >> However I do think this is a fun way to experiment with ICE and a very >> interesting way of coping with implementing NAT traversal outside >> end applications, so I am going to keep playing with this as time >> permits. So far except for tunnel setup speeds this looks very >> promising, and the least NIH that I have found. > > Meanwhile, my line will be to provide a working tunnel based on what > I already have. Delivering is more important to me, so I will be > a bit more conservative. As stated above, several of your > suggestions are directly usable, but not all are. I want to > thank you for all of them, and made quite a few notes for further > processing; I am interested in hearing what you will cook up! Sounds like a reasonable plan. > Once again, my apologies for the slow response. I'm afraid 6bed4 is > only one of my activities... no surprise there, I suppose ;-) No surprise there. Let me recommend to you rfc5128 "State of peer to peer communication across NATs", for it's vocabularly in talking about NATs. The vocabulary is much more specific and much more relevant then the vocabulary from RFC3489 STUN. Not that you want to fight NATs issues. But some at least when talking about bypass solutions it comes up. What is your vision for the set of problems you see 6bed4 solving? I think I have seen part of your vision when you said "Think alone of what it could do for peer-to-peer exchange of files in solutions (such as SIP, or chat, or YaCy) that are now fighting NAT traversal issues." You also mentioned not wanting to include both a full ipv4 stack and a full ipv6 stack, in thin embedded clients. The problem that is near and dear to my heart, is that when I talk to someone at a distance (say 2000 Kilometers) over a VOIP phone it works well if the RTP packets flow direction from my phone to the other parties. If the packets go through a relay connections are unreliable, and essentially undebugable. So I am very interested in figuring out which technologies will make those direct connections possible and easy to achieve. IPv6 is one of those technologies and ICE looks like it may be another. Eric |