About the workaround for the symetric NATs:
5.2.10 Working around symmetric NAT
[...] In many cases, it is possible to work around the limitations of
these NAT by explicitly reserving a UDP port for Teredo service on a
client, using a function often called "DMZ" in the NAT's manual.
This port will become the "service port" used by the Teredo hosts.
The implementers of Teredo functions in hosts must make sure that
the value of the service port can be explicitly provisioned, so that
user can provision the same value in the host and in the NAT.
The reservation procedure guarantees that the port mapping will
remain the same for all destinations. After the explicit
reservation, the qualification algorithm in section 5.2.1 will
succeed, and the Teredo client will behave as if behind a "cone
NAT".
We have been testing this for a long time, see the last section from http://www-rp.lip6.fr/teredo/ It is just a workaround, but it is not enough for many reasons.
Best regards, Vincent
Margaret Wasserman wrote:
Hi Eric, Henrik, Karen, Francis, Markku and Jonathan,
There is a new version of the Teredo draft available at:
http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-03.txt
Could you check whether this version addresses the issues that you raised during IETF LC? It would be best if you could review this document and return any feedback by this Thursday, 9-Dec-04.
If there are no further objections, I will place this draft on the IESG agenda for consideration on our 16-Dec-04 telechat.
Thanks!
Margaret