May I know what's the reason to against stateful other than stateless?
-Hui
2011/9/26 Rajiv Asati (rajiva) <rajiva@xxxxxxxxx>
That may be reasonable. And the document may reflect that.
> tunneling). It may be that the recommendation is specifically against
> *stateful* double translation
One could suggest rephrasing that para with something like this -
> > > 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 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
> Of teemu.savolainen@xxxxxxxxx
> -----Original Message-----
> From: softwires-bounces@xxxxxxxx [mailto:softwires-bounces@xxxxxxxx]
On Behalf
> Sent: Monday, September 26, 2011 11:20 AM
> To: satoru.matsushima@xxxxxxxxx; ietf@xxxxxxxx
> Cc: softwires@xxxxxxxx; behave@xxxxxxxx
> 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@xxxxxxxx [mailto:behave-bounces@xxxxxxxx] On
> > Behalf Of ext Satoru Matsushima
> > Sent: 13. syyskuuta 2011 06:51
> > To: ietf@xxxxxxxx
> > Cc: behave@xxxxxxxx; 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@xxxxxxxx mailing lists by 2011-09-14. Exceptionally, comments
may
> > > be sent to iesg@xxxxxxxx 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@xxxxxxxx
> > > https://www.ietf.org/mailman/listinfo/behave
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Behave mailing list
Behave@xxxxxxxx
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf