What happened to Teredo?

All replies

• 

  

  0

  Sign in to vote

  Teredo is IPv6 to IPv4 encapsulation. It's meant for a client using IPv6 to get around routers that are IPv4 only. I would guess that you're thinking more along the lines of L2TP tunneling for point to point access.
  
  The issue is that most NATs are not configured for port forwarding (which is generally a secure way to do things). So with the client relay, your client at home can get out the NAT on your Cable/FIOS/DSL router, to Mesh.com and find that there's a request from your work machine that's behind the corporate firewall. Otherwise, Your work machine (if it could resolve it) would just try to open up a socket on your home router, and have it stall there, unless port forwarding was preconfigured.
  
  The function of NATs/firewalls has always been to let whoever out, but not let people in. Two machines going out to the cloud is more reliable than trying to have one attempt to find a way in.

  • Edited by WillFa Thursday, May 29, 2008 11:04 PM embellished response.

  Thursday, May 29, 2008 10:57 PM
• 

  

  0

  Sign in to vote

  Yes, I understand that, but it can also be used for outside-in access, as it will provide your PC with a globally accessible IPv6 address, even if your PC is behind multiple NAT routers.
  
  If you've ever used "Remote Assistance" on Windows XP, it uses Teredo for exactly this purpose. So you can have somebody outside your local network access your PC to help you. It uses Teredo, and the remote person connects over RDP to your machine using Teredo/IPv6.
  
  

  Thursday, May 29, 2008 11:02 PM
• 

  

  0

  Sign in to vote

   Wouldn't that require that IPv6 be configured on the client?

  Thursday, May 29, 2008 11:06 PM
• 

  

  0

  Sign in to vote

  Even with remote assistance, the email has a link that acts as the broker for the teredo handshaking. When you send the invite, you're opening a connection point. When they respond, they connect to this open listener. Client relay acts as the broker. No need for a permanent open listener.
  People can't arbitrarily connect giving you assistance. You can arbitrarily connect to your machine over RDP through Live Mesh.
  

  Thursday, May 29, 2008 11:11 PM
• 

  

  0

  Sign in to vote

  Well it is on by default in Windows Vista. And MS is certainly pushing hard on IPv6 support with their customers/partners...
  
  A lot of stuff in Vista already requries IPv6, such as People Near Me, Meetings Near Me, etc. Even File/Printer sharing will try to use IPv6 and LLMNR.

  Thursday, May 29, 2008 11:11 PM
• 

  

  0

  Sign in to vote

   That's only because you do'nt want random people connecting to give you assistance. If the Teredo client was left running, you could technically arbitrarily RDP to your machine using your machines IPv6 address, if you so desired. (Assuming you have RDP enabled, and have setup permissions)

  • Edited by avs Thursday, May 29, 2008 11:15 PM added more content

  Thursday, May 29, 2008 11:14 PM
• 

  

  0

  Sign in to vote

  I was just saying that Remote Assistance uses Teredo to allow outside-in access to the remote person trying to help you... Without Teredo in this case, if you are behind a NAT router, the other person will have no way to connect to your machine.
  
  The machine can say, "Connect to me at 192.168.1.2" all it want's, it won't work. Teredo allows the other person to connect to your home machine via the IPv6/Teredo interface, even if the machine is behind a NAT router, and without the need to require the user to pre-setup mappings, etc.
  
  I was just saying that MS has already been pushing Teredo as the way to get into the home from outside, (they have described other scenarios that also rely on Teredo similar to the one I just described), so I thought it was wierd that this was not used in Live Mesh, and that Live Mesh solved the same problem by requiring the client to maintain a persistent SSL connection with a Live Mesh server, and further having the client poll said server every 25 seconds with an HTTP request.
  
  Just seems like more overhead than if they just used Teredo as the base infrastucture. Especially when you start getting into P2P synchronization of files, especially large files, Teredo would allow direct connetions between two clients behind NATs. Live-mesh currently will route all that traffic through the server, creating a bottleneck.

  Thursday, May 29, 2008 11:24 PM
• 

  

  0

  Sign in to vote

  I think client relay would be the simplest way instead of figuring out IPv6 relay configuration for your mac or smartphone. Wonder if you could RDP a smartphone or use it as a client?
  
  Perhaps in the future we'd see this. As a CTP though, I'd guess client relay was the quickest and simplest way to get the core functionality out the door.
  
  (And thinking about my email brokering the handshaking comment... It'd be just as feasible to have a client sync a teredo request up the mesh, and the host sync it back down and process it.)
  
  On further thought, I'd guess that would fall under the realm of P2P functionality, and for the CTP MS would want as much log data as possible, thus the dependence on the cloud.
  
  

  Thursday, May 29, 2008 11:29 PM
• 

  

  0

  Sign in to vote

  Great discussion so far. You've hit on some of the key points in any P2P mechanism - the desire to use the fastest available network, the need for secure access, avoidance of opening yourself up to attacks, etc.
  
  Today, Live Mesh uses both relays and direct connections (when available, such as both machines on the same LAN). The connection setup process involves exchanging addresses between peers, and can only happen if both peers already have a relationship - for instance, they sync the same live folder. (You didn't ask, but it turns out the communication is fully encrypted e2e as well).
  
  We are definately looking at other techniques for establishing P2P connections, including Teredo, for future releases.
  
  AVS, you bring up 2 issues:
  1. The "RDP session seems painfully slow".  This may be a bug/configuration issue. Would you share your logs with us so we can take a look?
  
  2. "the client poll [the] server every 25 seconds with an HTTP request". This is actually our mechanism for state refresh. The client can potentially cache a number of items, live folders, device status, news entries, etc. To keep that state fresh without reverting back to polling, we use a publication/subscription mechanism. Those HTTP requests are actually this notification mechanism in action. We also leverage this notification channel for the signalling mechanism I mentioned above.

  • Marked as answer by Ben [Live Mesh] Friday, May 30, 2008 6:16 PM

  Thursday, May 29, 2008 11:43 PM
• 

  

  0

  Sign in to vote

  You only need an IPv6 relay if you are connecting a native IPv6 client to a Teredo Client. Otherwise the setup is very easy, as the packets sent on the wire are essentially IPv6 packets encapsulated in an IPv4 UDP packet. Basically all the client has to do is wrap the IPv6 packet in IPv4/UDP and send it to the other machine's IPv4 address, which is encoded in the Teredo/IPv6 address...
  
  Configuration for Mac would be easy since Teredo is already supported on OS X. Most all smartphones already have native IPv6 stacks today as well, as places like Japan and Korea have pushed for this many years ago in anticipation of migrating their telecommunications networks to IPv6. In fact, Korea, Japan, and the US, already have government mandates for IPv6.
  
  The Teredo protocol itself is very lightweight so even if you needed to install/create one, it's pretty straight-forward. (Especially since it's an open spec)
  

  Thursday, May 29, 2008 11:43 PM
• 

  

  0

  Sign in to vote

  Sure no problem... Where do I get the logs from?
  
  Since we're talking about bugs... I noticed that if I'm RDPed to a machine using the RDP Client.... Then try to remote to the same machine using Live Mesh from another machine while that other RDP session is active....
  
  Live Mesh will still bring up the remoting window, it will still authenticate, it will still attempt a connection, then say it's connected, but the screen is black. You can move the cursor and everything, and from the user's perspective all seems normal, except for the black screen...
  
  Meanwhile, the RDP session on the other machine is still functional, and is still working correctly... In order to get the Live Mesh remoting session to work, you have to exit the other RDP session, then disconnect the Live Mesh remoting session, then re-connect the Live MEsh remoting session...
  
  
  Edge case I'm sure, but from a user perspective, no errors were apparent :)

  • Edited by avs Thursday, May 29, 2008 11:50 PM clarified

  Thursday, May 29, 2008 11:49 PM
• 

  

  0

  Sign in to vote

  I'll get back to you on the right way to collect logs.
  
  We have 2 forms of remote desktop right now, one which requires a service to be installed, and one which does not. It sounds like you are running the latter. This form uses screen scraping and runs within the windows session, so among other things can't display anything if the windows session is locked (screen saver on, a different RDP session exists, etc.).
  
  To get the other form, you have to take an additional install step on Vista. On the notifier pane (which you get by clicking on the taskbar icon), you should see a tab on the far left, which gives you a link for installing remote desktop extensions (I'm not sure of the exact text). This requires UAC elevation, btw.
  
  With this more advanced form, you actually create a windows session, similar to (and written by the same team) the way RDP works. You'll likely get a better experience with that.

  Friday, May 30, 2008 12:00 AM
• 

  

  0

  Sign in to vote

  the enhancements were already installed :)

  Friday, May 30, 2008 12:12 AM
• 

  

  0

  Sign in to vote

  Hi avs,
  
  I'm sorry for the delay in responding here.
  
  The black screen issue you're seeing with your Live Mesh Remote Desktop has been reported by a few others, and we're still working to fix the problem.  Please feel free to validate this bug on the Live Mesh Connect site; the Connect Bug ID is 346729.
  
  As for collecting logs and getting them to the team, the instructions are below.
  
  Thanks for helping us test Live Mesh, and for the lively discussion in this thread!
  
  Ben.
  
  

  ------------------------------------------------

  To submit a bug with your logs attached:

  Please go to http://connect.microsoft.com/. Sign in and then select Live Mesh Tech Preview on Your Dashboard.  Click Feedback and follow the instructions for collecting your logs and then submit a bug.
  
  To get your logs:
  
  1.  Click Start.
  2.  Select All Programs and look for the Live Mesh folder.
  3.  Click Collect Live Mesh Logs.
  4.  Your logs will be bundled together in a cab file now located on your desktop.
  
  Attach your LiveMeshLogs.cab file located on your desktop to your bug.

  Note: you will have to submit a bug first, then edit it to attach your logs.        

  If you do not have access to the Live Mesh Connect site, you can email your logs to lmprev@microsoft.com.  Please provide as much information about your issue as you can in that email.

  • Marked as answer by Ben [Live Mesh] Friday, May 30, 2008 6:16 PM

  Friday, May 30, 2008 6:16 PM
• 

  

  0

  Sign in to vote

  David - Live Mesh said:

  2. "the client poll [the] server every 25 seconds with an HTTP request". This is actually our mechanism for state refresh. The client can potentially cache a number of items, live folders, device status, news entries, etc. To keep that state fresh without reverting back to polling, we use a publication/subscription mechanism. Those HTTP requests are actually this notification mechanism in action. We also leverage this notification channel for the signalling mechanism I mentioned above.

  
  Thanks David.  I am being thick or missing something cool.  If the client is doing HTTP request every 25 seconds, is that not polling?
  
  Is it making request on same socket or is socket closed after each request and new one open on next request?
  

  Friday, May 30, 2008 7:07 PM
• 

  

  0

  Sign in to vote

    I may be wrong, but Polling is generally pulling information. A program could poll to request new updates. I'd guess that local moe's actually pushing changes up to the cloud. i.e.:
  Online: True
  Available for RDP: True
  Folder Updates locally: 0
  News updates: 0
  Permission updates: 0
  
  Mesh.com would only need to push folder, news, and membership changes down to subscribers, since online and rdp status updates don't make sense for it.
  
  
  Would it be safe to assume that when P2P functionality comes out that even if data doesn't go up to the cloud, all metadata has to? Otherwise, how would your work computer know that there's an update on your home pc without having CloudMOE broker a teredo handshake or something? Does LocalMOE only subscribe to feeds from the cloud? If MediaCenterPC and HomeOfficePC, although being on the same segment, lose internet connectivity, synchronization between them will break because they can't get to Mesh.com for metadata updates? Or is this just the case in the CTP, since reflecting on Ori's video, he mentioned the "cheapest fastest route". And the product's called Mesh, not Star after all.
  
  Going back to my AD analogy from another post, Even if LocalMOEs can subscribe to one another, you'll still need a "RID master" and "Infrastructure master". Mesh.com would be the logical and best choice for these "FSMO roles".
  Am I getting ahead of myself again? :)

  Friday, May 30, 2008 8:09 PM
• 

  

  0

  Sign in to vote

  If you have two P2P clients, why would they need to go to the cloud for metadata? You could have the two clients subscribe to feeds on each other. You wouldn't technically need CloudMOE for anything, it wouldn't even need to broker a teredo handshake. If the client has the Teredo address of the other machine, that's all it needs. One thing you could use the cloud for is authentication/authorization to make sure each party has sufficient permissions.
  
  Obtaining the Teredo Address in the first place is a different matter, but there are already a solutions for that that.
  
  But anyways, one machine will know of updates on the othre machine based on the feed. The main reason for involving the Cloud in this scenario of LiveMesh, is to try to solve the problem if one of the machines goes offline. But that is a separate and independent issue, that can be solved by other means.
  
  The way the polling of LiveMesh works (from what I understand), is that the client issues a request. When the server needs to make a request on the client (or publish a notification, which is technically still an HTTP request), it encapsulates the request as the response to the periodic request sent by the client. (This is also known as reverse-http). The reason the client doesn't just keep the connection persistent, and periodically issues a new request every 25 seconds, is behaviorial, as some servers/proxies/intermediaries/etc will idle/timeout a connection.
  
  (Note: I'm not advocating Teredo as a perfect solution)
  If Teredo were used as the connection infrastructure, you wouldn't have to integrate this functionality with your communication mechanism, as Teredo will take care of the network connectiivty for you. This way you could use a true web-service model, where the client need not periodically issue a request to the server. The server can issue it's own request, or publish announcements whenever appropriate.
  
  This way, you won't need to consume additional resources on each side of the connection to maintain the persistent TCP session. You'll also get better responsiveness because it will be truely event driven.

  • Edited by avs Friday, May 30, 2008 8:33 PM clarification

  Friday, May 30, 2008 8:29 PM
• 

  

  0

  Sign in to vote

  CloudMOE would be the broker/directory of teredo addresses. "If the client has it" leads to the question "how do they get it if they don't?" The answer is CloudMOE. P2P is more than local segment connections as well. CloudMOE has routing information on how PC-A can establish a direct connection to PC-B (Ori mentioned "cheapest" in the Channel 9 vid). You also have the authentication that you bring up.
  "Need CloudMOE for anything": Each entity in the feed has a guid associated with it. Although the GUID generation algorhythm has MAC and time built into it, without a single authoritative source there's still a (albeit remote) possiblity for duplicates. Replicating Metadata to all clients increases geometrically the amount of data that you store. Unless it's normalized which LocalMOE can do. Thinking more about it, I may be wrong. I assumed a "RID master" type functionality is needed because of my understanding of AD. But even RID is a throw back to NT4 interop and SID generation, so may not be applicable to a feed with an entity's guid and an creation-source attribute declaring it authoritative for that entity. Standard collision detection could detect the remote possibility of identitical guids from different devices.
  
  Your reverse-http comments make definite sense.
  
  Especially with the Internet, I prefer "chunky" to "chatty" protocols. But how do you universally get a public-facing listener? uPnP? Doesn't work in corporate environments, etc etc. I guess this is what Ori meant when he said that http is the universal protocol today. With 440 million potential users, with multiple devices, is designing a chatty protocol setting yourself up for a DoS?
  
  
  Okay, we're spit-balling design choices that were made 2 years ago. I want the SDK already. :)
  
  Going out to watch the Celtics game... catch ya tomorrow
  

  • Edited by WillFa Friday, May 30, 2008 9:16 PM Embellishment

  Friday, May 30, 2008 8:58 PM
• 

  

  0

  Sign in to vote

  Teredo will give you a public listener. It essentially incorporates the STUN protocol to identify the port mapping at the edge router. It sends a periodic UDP bubble packet to keep the port mapping alive. (This is much less heavy weight than keeping a TCP/SSL connection alive, since the bubble packets are stateless, and very tiny)
  
  Teredo is an open standard published by the IETF, and MSFT already incorporated a Teredo Client in both XP and Vista. The mechanism by which that NAT traversal of Teredo is based (STUN) is already widely deployed and used for VoIP and Online gaming today.
  
  You can think of Teredo as a sort of VPN. It provides a globally unique and accessible IPv6 address for each and every client within the home. You can interact with these interfaces just as if they were local, even running IPSec over it if you wanted, etc.
  
   I did not mean to imply that the use of a persistent SSL connection was a bad decision, it is certainly needed in some scenarios where Teredo might not work. I was just asking why Teredo funtionality for outside-in access was absent from LiveMesh, when it is already incorporated and/or emphasized by othre groups within Microsoft.
  
  

  • Edited by avs Friday, May 30, 2008 9:31 PM clarification

  Friday, May 30, 2008 9:27 PM
• 

  

  0

  Sign in to vote

  It may just be that what we're seeing today is the result of 2 years work, and teredo wasn't far enough along or universally accepted to make it a choice.
  
  Oh, I just stumbled across this. Interesting read about the authetication and encryption. Metadata does go to the cloud for the clients that can't direct connect. The other thing that I suspected was about the cloud storage. "[S]trong access controls" isn't the same as encrypted. This desgin choice was most likely so that they can Live Search index your Live Desktop for you, but I'm curious as to whether or not those indexes will be datamined and leveraged for advertisement placement. It's still a business and they'll need to recoup costs/make a profit somehow after all. I'm not anymore at ease on what I put in the cloud. :)
  
  Anyway, I'm really leaving now! I swear...

  Friday, May 30, 2008 9:36 PM
• 

  

  0

  Sign in to vote

  Heh heh, I read that yesterday too. I even ran it through our security folks... After I scraped their jaws off the floor, they tried to reassure me that it wasn't that bad as long as the only way to access said data was through their strong safeguards. Not sure it makes me any more comfortable to trust my sensitive docs on there... But I certainly wouldn't trust it for any of my work documents without at least encrypting it first.

  Friday, May 30, 2008 9:47 PM
• 

  

  0

  Sign in to vote

  If I have a client that maps one core object, it polls once every 25 seconds or so. If I have a client that maps 100 core objects, it polls once every 25 seconds or so. We poll just the one feed.
  
  A more obvious way to do this would be to poll each core object, but then the load would be proportional to the amount of stuff I cached.
  
  Hope that helps answer your question.
  
  

  • Marked as answer by Ben [Live Mesh] Tuesday, June 3, 2008 8:20 PM

  Tuesday, June 3, 2008 1:57 AM