Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard

From: Satoru Matsushima <[email-masked]>
Date: Tue, 13 Sep 2011 12:50:59 +0900

The introduction in the draft says:

>   IETF recommends using dual-stack or tunneling based solutions for
>    IPv6 transition and specifically recommends against deployments
>    utilizing double protocol translation.  Use of BIH together with a
>    NAT64 is NOT RECOMMENDED [RFC6180].
> 

This statement makes a strong obstacle when we develop stateless solution with translation in softwires wg.
I think that it is still remained a room to make decision whether removing the statement or remaining it. 
The discussion which we'll have in the softwires interim meeting would be helpful to decide it.

Best regards,
--satoru

On 2011/08/31, at 22:53, The IESG wrote:

> 
> The IESG has received a request from the Behavior Engineering for
> Hindrance Avoidance WG (behave) to consider the following document:
> - 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)'
>  <draft-ietf-behave-v4v6-bih-06.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-09-14. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol
>   translation mechanism that allows a class of IPv4-only applications
>   that work through NATs to communicate with IPv6-only peers.  The host
>   on which applications are running may be connected to IPv6-only or
>   dual-stack access networks.  BIH hides IPv6 and makes the IPv4-only
>   applications think they are talking with IPv4 peers by local
>   synthesis of IPv4 addresses.  This draft obsoletes RFC 2767 and RFC
>   3338.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 12 Sep 2011 20:56:17 -0700

> The discussion which we'll have in the softwires interim meeting would be
helpful to decide it.

+1

Nat464 has been shown to overcome real world issues, it solves a real
problem.

Additionally the bih mapper should not have to require DNS so that ipv4
literals can be overcome

Cb

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf