tunneling). It may be that the recommendation is specifically against
*stateful* double translation
That may be reasonable. And the document may reflect that.
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].
One could suggest rephrasing that para with something like this -
This document doesn't recommend using BIH together with NAT64
[RFC6180]. Of course, the adoption of this or any solution (e.g
dual-stack and/or any solution that eases the path to IPv6
(and accommodate residual IPv4)) would be subjected to the
overall cost-effectiveness, as determined by operators per their
environments/constraints.
Cheers,
Rajiv
-----Original Message-----
From: softwires-bounces(_at_)ietf(_dot_)org
[mailto:softwires-bounces(_at_)ietf(_dot_)org]
On Behalf
Of teemu(_dot_)savolainen(_at_)nokia(_dot_)com
Sent: Monday, September 26, 2011 11:20 AM
To: satoru(_dot_)matsushima(_at_)gmail(_dot_)com; ietf(_at_)ietf(_dot_)org
Cc: softwires(_at_)ietf(_dot_)org; behave(_at_)ietf(_dot_)org
Subject: Re: [Softwires] [BEHAVE] Last
Call:<draft-ietf-behave-v4v6-bih-
06.txt> (Dual Stack Hosts Using"Bump-in-the-Host" (BIH)) to Proposed
Standard
Please note that this statement was included after quite long and
heated
discussion in behave WG and because it came clear that IETF
recommendation
is against double protocol translation (in favor of dual-stack and
tunneling). It may be that the recommendation is specifically against
*stateful* double translation (although that was not said aloud, if I
recall
correctly).
I would assume softwires follows these same IETF guidelines and
therefore is
now focusing solely on stateless approaches(?). If the IETF opinion
has
changed so that also stateful double translation solutions are now ok
for
IETF, then that should perhaps be reflected in this document as well.
Unfortunately, I did not have chance to go to softwires interim, but
please
let us know if the discussions there impact also the quoted
recommendation.
Best regards,
Teemu
-----Original Message-----
From: behave-bounces(_at_)ietf(_dot_)org
[mailto:behave-bounces(_at_)ietf(_dot_)org] On
Behalf Of ext Satoru Matsushima
Sent: 13. syyskuuta 2011 06:51
To: ietf(_at_)ietf(_dot_)org
Cc: behave(_at_)ietf(_dot_)org; Satoru Matsushima
Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt>
(Dual
Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard
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
ietf(_at_)ietf(_dot_)org mailing lists by 2011-09-14. Exceptionally,
comments
may
be sent to iesg(_at_)ietf(_dot_)org 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
Behave(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Behave mailing list
Behave(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf