IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)
RFC 5572

[Ballot discuss]
It was made fairly clear when chartering the softwires working group that overlapping work would be rejected by the IESG via RFC3932 until softwires completed its work. This was key in helping to focus the group, and a number of protocols have been held up in this vein. Therefore, I believe we should go with your option number 3 until softwires finishes its chartered overlapping items. Doing otherwise would be inconsistent with what we have done already. If it helps, I will commit to shepherding this document once softwires has completed its standards-track work.

[Ballot discuss]
It was made fairly clear when chartering the softwires working group that overlapping work would be rejected by the IESG via RFC3932 until softwires completed its work. This was key in helping to focus the group, and a number of protocols have been held up in this vein. Therefore, I believe we should go with your option number 3 until softwires finishes its chartered overlapping items. Doing otherwise would be inconsistent with what we have done already. I will be happy to shepherd this document personally once softwires has completed its standards-track work.

[Ballot discuss]
If we can mandate the warning note proposed in the ballot writeup then I am okay with this publishing. Question to IESG: Should we put this in the RFC editor's note? The note that I am referring to is:

      The content of this RFC was at one time considered by the IETF,
      and therefore it may resemble a current IETF work in progress or a
      published IETF work.  This RFC is not a candidate for any level of
      Internet Standard.  The IETF disclaims any knowledge of the
      fitness of this RFC for any purpose and in particular notes that
      the decision to publish is not based on IETF review for such
      things as security, congestion control, or inappropriate
      interaction with deployed protocols.  The RFC Editor has chosen to
      publish this document at its discretion.  Readers of this RFC
      should exercise caution in evaluating its value for implementation
      and deployment.  See RFC 3932 for more information.

[Ballot comment]
I also are in favor of note 3. I don't think we need even more NAT traversal solutions, especially one that are incomplete and badly charaterized. Although this solution may not be one of the more useful as it doesn't specify IPv4 over IPv4 tunnels.

[Ballot comment]
I am in favor of 3 - this document is way under-specified and claims things about NAT traversal that are not true. I see it causing harm by convincing people that this solves problems that softwire does not when in reality it does not solve the problems.

IANA Evaluation Comments:

IANA understands that there is a single action required upon approval
of this  document.

A new registry will be created in the IANA Matrix. A new area called "Tunnel
Setup Protocol" will be created in the IANA Matrix and a single entry will be
made under it called: "Tunnel Types" which will point to a new registry with
a  location to be determined later.

The initial values of this registry will be:

Tunnel
Type: Description Reference
------- --------------------------------------- ---------------
v6v4 IPv6 in IPv4 encapsulation (using IPv4
protocol 41)
v6udpv4 IPv6 in UDP in IPv4 encapsulation
v6anyv4 IPv6 in IPv4 or IPv6 in UDP in IPv4
encapsulation
v4v6 IPv4 in IPv6 encapsulation.

Future values for this registry are to be established on a first come first
served basis.

The IANA notes that IANA already assigned 3653 as the port number for
this  protocol.

IANA understands that the creation of this new registry is the only action
required upon approval of this document.