Re: Miredo OSX Prerelease2

Re: [LONG] RFC: handling of symmetric NATs

My general inclination would be to keep the check, as it is useful  
for debugging at the very least.

However, I would add an extra feature... If miredo is indeed behind a  
symmetric NAT, then miredo can immediately know that any attempts to  
send packets to other miredo clients will fail---and can thus send  
back an ICMPv6 type 1 ("Destination Unreachable") message. This will  
allow programs attempting to contact other miredo addresses to fail  
more quickly.

Ideally one of the bits in the miredo address would be set if the  
client was behind a symmetric NAT. That way other miredo clients  
could send ICMPV6 Type 1 replies to attempts to send packets to  
clients behind symmetric NATs. I don't know how responsible it would  
be to implement such behavior without an update to the RFC. :/

One depressing point though... The Microsoft teredo servers (which  
are the default teredo servers for Windows Vista) *do not* perform  
the ICMPv6 forwarding. Thus, if you are using the Microsoft teredo  
servers (teredo.ipv6.microsoft.com), you can *only* connect to other  
teredo addresses. You *cannot* connect to native IPv6 addresses with  
the Microsoft teredo servers! This is immensely depressing.

On Mar 31, 2007, at 10:03 AM, Rémi Denis-Courmont wrote:

> 	Hello,
>
> For the past year, there has been a large (relative to the tiny
> userbase) ammount of complaints about the way miredo does -not- handle
> symmetric NATs.
>
> A change is probably long overdue, but I am not too sure what to do.
>
> To put things into their context, the Teredo protocol (as in IETF
> Proposed Standard RFC4380) defines the Teredo client "Qualification
> procedure". This is a process that the client runs at startup to
> determine what kind of NAT it is located behind, if any. That's a
> simplification of the original STUN NAT traversal protocol defined
> earlier (RFC3489). Since then, the IETF crowd figured out that NAT
> classification was far too brittle, and simply did not work properly.
> The next version of the STUN protocol (draft-ietf-behave-rfc3489bis)
> simply got rid of the whole NAT determination procedure, and only  
> keeps
> IP/port mapping and NAT binding maintenance.
>
> Also, NAT refresh interval determination has been deprecated from  
> STUN,
> and still is in Teredo. Good news here: Miredo never implemented it in
> the first place as it was a tricky optional feature :)
>
> Last year, I removed "cone" NAT detection. This is a violation of the
> Teredo protocol, but it had proven too brittle. A nice side-effect was
> that Miredo became much faster to initialize.
>
> Another important change has been the addition of a way to receive
> packets from other Teredo peers behind symmetric NATs. That is also a
> violation of the Teredo protocol, but I believe Windows Vista does the
> same, at least if I am to trust Microsoft documentation (I do not have
> Vista). Besides, there is always the chance that a standard-conformant
> Teredo client believes it's behind a restricted NAT, while it's really
> a symmetric NAT, and that was definitely needed to avoid breaking
> these.
>
> Still, to date Miredo (apart from Miredo-OSX which has a patch for  
> this)
> refuses to run when it detects it is behind a symmetric NAT. Per
> RFC3489bis, it should not even detect this situation. I have not heard
> of any plan to update the Teredo protocol specification at this stage,
> though Vista obviously introduces some undocumented changes.
>
> One option is to drop NAT type determination altogether and assume
> port-restricted NAT always. On the one hand, this simplifies the code,
> follows the spirit of RFC3489bis, and will surely improve Miredo
> usability to reach the native IPv6 Internet from behind NAT. On the
> other hand, it will increases the chance that Teredo-to-Teredo
> communications break - in a way; what this means, is that Teredo
> clients will really be third class IPv6 citizens. Robert Quattlebaum
> (the nice guy behind Miredo-OSX) pointed out this was already the case
> anyway. Teredo is indeed defined as a last-resort tunneling protocol.
>
> Interestingly, that means the Teredo secondary server address becomes
> redumdant (though still needed for backward compatibility).
>
> Another option is to keep the procedure as it is but ignore the result
> (that's what Miredo-OSX currently does).
>
> A third option is to change nothing and keep getting complaints.
>
> Of course, there could be a configuration switch... but I do not like
> configuration switch, since 99,9% of users will not have any clue how
> to use it, and most of the remainders will think the option does some
> miracle that it does not actually do and misuse it.
>
> I would tend to favor the first option at this point. Opinions are
> welcome. Also, infos about Vista Teredo tunnel are welcome.
>
> Regards,
>
> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/

__________________
Robert Quattlebaum
Jabber: darco@...
eMail:  darco@...
www:    http://www.deepdarc.com/

Re: [LONG] RFC: handling of symmetric NATs

On Apr 2, 2007, at 3:43 AM, Bernhard Schmidt wrote:

> Robert B Quattlebaum, Jr. wrote:
>
>> One depressing point though... The Microsoft teredo servers (which  
>> are the default teredo servers for Windows Vista) *do not* perform  
>> the ICMPv6 forwarding. Thus, if you are using the Microsoft teredo  
>> servers (teredo.ipv6.microsoft.com), you can *only* connect to  
>> other teredo addresses. You *cannot* connect to native IPv6  
>> addresses with the Microsoft teredo servers! This is immensely  
>> depressing.
>
> Uh, how do you figure? I did not try it myself, but I do see some  
> amount of traffic on my global Teredo relay with Microsoft servers  
> encoded in the client address, which would not be possible.

Interesting. I tried using teredo.ipv6.microsoft.com as the teredo  
relay for miredo, and it didn't seem to work... I could only connect  
to other teredo clients. This was a few weeks ago though. Maybe the  
Miredo client doesn't work with Microsoft's teredo servers...?

__________________
Robert Quattlebaum
Jabber: darco@...
eMail:  darco@...
www:    http://www.deepdarc.com/

Re: [LONG] RFC: handling of symmetric NATs

On Apr 2, 2007, at 6:31 AM, Robert B Quattlebaum, Jr. wrote:

> On Apr 2, 2007, at 3:43 AM, Bernhard Schmidt wrote:
>
>> Robert B Quattlebaum, Jr. wrote:
>>
>>> One depressing point though... The Microsoft teredo servers  
>>> (which are the default teredo servers for Windows Vista) *do not*  
>>> perform the ICMPv6 forwarding. Thus, if you are using the  
>>> Microsoft teredo servers (teredo.ipv6.microsoft.com), you can  
>>> *only* connect to other teredo addresses. You *cannot* connect to  
>>> native IPv6 addresses with the Microsoft teredo servers! This is  
>>> immensely depressing.
>>
>> Uh, how do you figure? I did not try it myself, but I do see some  
>> amount of traffic on my global Teredo relay with Microsoft servers  
>> encoded in the client address, which would not be possible.
>
> Interesting. I tried using teredo.ipv6.microsoft.com as the teredo  
> relay for miredo, and it didn't seem to work... I could only  
> connect to other teredo clients. This was a few weeks ago though.  
> Maybe the Miredo client doesn't work with Microsoft's teredo  
> servers...?

After further testing, it would now appear that Microsoft's teredo  
servers are working properly, even with Miredo. I imagine that this  
is something that was fixed relatively recently. Sorry for any  
confusion.

__________________
Robert Quattlebaum
Jabber: darco@...
eMail:  darco@...
www:    http://www.deepdarc.com/

Re: [LONG] RFC: handling of symmetric NATs

Le lundi 2 avril 2007 10:34, Robert B Quattlebaum, Jr. a écrit :
> However, I would add an extra feature... If miredo is indeed behind a
> symmetric NAT, then miredo can immediately know that any attempts to
> send packets to other miredo clients will fail---and can thus send
> back an ICMPv6 type 1 ("Destination Unreachable") message. This will
> allow programs attempting to contact other miredo addresses to fail
> more quickly.

I don't know if that would suffice to generate a non-blocking error, 
which is what many software expect. In any case, on operating systems 
with correct RFC3484, this problem should pretty much never happen as 
Teredo will be attempted last always (i.e. even after IPv4 if 
available).

In that context, it might be better try to connect anyway, even if there 
is only 1% chance that it works.

The real problem are not-quite-old systems that haven't updated to a 
shiny new C library with RFC3484 or whose library hasn't added the 
Teredo prefix :( (glibc 2.5 has RFC3484 but not Teredo for instance)

> Ideally one of the bits in the miredo address would be set if the
> client was behind a symmetric NAT. That way other miredo clients
> could send ICMPV6 Type 1 replies to attempts to send packets to
> clients behind symmetric NATs. I don't know how responsible it would
> be to implement such behavior without an update to the RFC. :/

We could consider how risky it would be to unilateraly take a bit... but 
is there any bit available?

From the Teredo flag part:
* 8000 is the cone flag from RFC4380,
* 4000 was the random Teredo ID bit from draft-ietf-ngtrans-shipworm-07
* 0200 is the EUI64 unicast id bit from IEEE and IPv6,
* 0100 is the EUI64 group bit,
* the other 12 bits are filled pseudo-randomly by Vista to increase the
  difficulty in guessing a valid Teredo address (non-standard, but
  non-neglectible).

Only 4000 might be usable, but it's not even clear that it won't break 
old Microsoft Teredo clients (Windows XP?). I am currently not aware of 
any significant deployment of Miredo (read: any vendor that ships it or 
intends to do so). And without that, there will not be much support for 
allocating a new bit, whether officially through IETF or not; I mean, 
Microsoft might happily take the bit and do something incompatible with 
it.

Thanks for your input.

Regards,

--

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Re: Miredo OSX Prerelease2

Le lundi 2 avril 2007 10:05, Robert B Quattlebaum, Jr. a écrit :
> One thing that is missing is the code to actually check for the
> frameworks... I was lazy and just left it out because my working copy
> was only for the Mac anyway.

Trunk checks for Darwin. That's evil/lazy, but does not break other 
platforms - including mine :P

(...)
> 1) Whenever miredo tries to remove the default IPv6 route it added,
> it ends up removing whatever the current default IPv6 route is,
> regardless of what interface the default route is using. This is bad
> because if the teredo tunnel is being taken down because native IPv6
> connectivity has been obtained, this will *break* whatever ipv6
> connectivity has been already established. I have toyed around with
> this trying to figure out an elegant fix, but I have yet to come up
> with one. I'm assuming this only happens on MacOS X, and possibly on
> BSD variants.

Most probably a bug in libtun6 BSD route deletion code :-$ I am 
currently getting rid of it, and replacing it with callback scripts 
though.

> 2) Every once and a while, one of the miredo threads will get stuck
> in an infinite loop. What seems to cause this is when I wake up my
> mac on a network with native IPv6 when the mac was previously using
> miredo for IPv6 before it was put to sleep. I haven't had time to
> really look into this issue.

The way addrwatch currently works is a bit of an unstable system. Can 
you reproduce the problem when NOT in autoclient mode?

> 3) Miredo doesn't detect changes in the network configuration, so it
> takes a long time (~20 seconds) for it to update itself. This can be
> fixed by using the system configuration framework to listen for
> network changes. I guess this is more of a new feature than a huge
> problem though...

Pretty much since version 0.2.0 (the first one with client support), 
there's this FIXME in libteredo/maintain.c that the code should poll 
for IPvFOUR networking changes. Then, it could immediatly force a 
binding update. The annoying part is that it's heavily OS-dependant.

Another part of the problem lies in avoiding network configuration 
events polling in two different parts of the code (there is the 
autoclient support elsewhere...).

--

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Re: [LONG] RFC: handling of symmetric NATs

Replying to myself.

Another problem is what Teredo clients behind non-symmetric NAT should 
do when they get non-Teredo IPv6 connectivity, and try to reach another 
Teredo clint.

Ideally, they'd try Teredo, and use native if it fails, but it's 
practically impossible to work this out with a mere tunnel interface. 
No go.

So there has to be a choice. Native might provide lower bandwidth and 
higher latency because it will depend upon Teredo relays, but it should 
have a better reliability.... As long as there are working Teredo 
relays.

Le samedi 31 mars 2007 20:03, Rémi Denis-Courmont a écrit :
> One option is to drop NAT type determination altogether and assume
> port-restricted NAT always. On the one hand, this simplifies the
> code, follows the spirit of RFC3489bis, and will surely improve
> Miredo usability to reach the native IPv6 Internet from behind NAT.
> On the other hand, it will increases the chance that Teredo-to-Teredo
> communications break - in a way; what this means, is that Teredo
> clients will really be third class IPv6 citizens. Robert Quattlebaum
> (the nice guy behind Miredo-OSX) pointed out this was already the
> case anyway. Teredo is indeed defined as a last-resort tunneling
> protocol.

--

-- 
Rémi Denis-Courmont
http://www.remlab.net/

NAT-PMP support ?

	Hello,

I have been considering adding support for NAT-PMP hole punching in 
Miredo. Contrary to UPnP, this protocol actually looks both sane and 
lightweight (UPnP uses XML over HTTP over UDP(!) over IP multicast...).

My main concern is that I don't have any NAT-PMP-capable gear to test 
with. Another problem is the need for some damn platform-specific code 
to extract the IPv4 gateway address from the operating system.

Comments are welcome - maybe it's not a good idea (?).

Regards,

--

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Re: NAT-PMP support ?

On Apr 11, 2007, at 12:54 PM, Rémi Denis-Courmont wrote:

> I have been considering adding support for NAT-PMP hole punching in
> Miredo. Contrary to UPnP, this protocol actually looks both sane and
> lightweight (UPnP uses XML over HTTP over UDP(!) over IP  
> multicast...).
>
> My main concern is that I don't have any NAT-PMP-capable gear to test
> with. Another problem is the need for some damn platform-specific code
> to extract the IPv4 gateway address from the operating system.
>
> Comments are welcome - maybe it's not a good idea (?).

I'm a little confused as to what specific benefit this would provide.  
If a router is a symmetric NAT, I would think the likelihood that it  
supports NAT-PMP is quite low. In any other case, teredo should "just  
work" anyway, right?

The only benefit that I can see would be that it would allow for more  
stable teredo addresses to be assigned, but even the utility of this  
is questionable. Maybe it could speed up the setup process?

__________________
Robert Quattlebaum
Jabber: darco@...
eMail:  darco@...
www:    http://www.deepdarc.com/

Re: NAT-PMP support ?

   Hello,

On Mon, 16 Apr 2007 13:42:55 -0700, "Robert B Quattlebaum, Jr." <darco <at> deepdarc.com> wrote:
> I'm a little confused as to what specific benefit this would provide.  
> If a router is a symmetric NAT, I would think the likelihood that it  
> supports NAT-PMP is quite low. In any other case, teredo should "just  
> work" anyway, right?

Hmm, true. You are the Apple guy, so you may know how NAT-PMP middleboxes behave.
However, using NAT-PMP (or UPnP for that matter) should turn even a
restricted NAT into a full cone NAT. That would allow peers behind a symmetric
or non-deterministic NAT to make contact with you, while they couldn't if you
had not only a symmetric, but also a restricted/port-restricted NAT.

> The only benefit that I can see would be that it would allow for more  
> stable teredo addresses to be assigned, but even the utility of this  
> is questionable. Maybe it could speed up the setup process?

Since cone probing was withdrawn, the setup process is already quite fast:
two round trips, while it used to be 16 seconds plus two round trips.

Regards,

--
Rémi Denis-Courmont
http://www.remlab.net/