Re: [LONG] RFC: handling of symmetric NATs
Robert B Quattlebaum, Jr. <darco@...
2007-04-02 07:34:02 GMT
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
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:
> For the past year, there has been a large (relative to the tiny
> userbase) ammount of complaints about the way miredo does -
> 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
> IP/port mapping and NAT binding maintenance.
> Also, NAT refresh interval determination has been deprecated from
> 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
> Still, to date Miredo (apart from Miredo-OSX which has a patch for
> 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.
> Rémi Denis-Courmont