> -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > teemu.savolainen@xxxxxxxxx > Sent: Monday, September 26, 2011 8:20 AM > To: satoru.matsushima@xxxxxxxxx; ietf@xxxxxxxx > Cc: softwires@xxxxxxxx; behave@xxxxxxxx > Subject: RE: [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 believe the objection is against "non-deterministic translation", rather than stateful versus stateless. By non-deterministic, I mean that the subscriber's equipment (e.g., CPE) cannot determine the mapping it will have on the Internet. A+P mechanisms are deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). A stateful CGN, as commonly deployed, is not deterministic. However -- and this is my point in this email -- a stateful CGN can be configured and deployed so that it deterministically maps traffic. That is, it can function very much like A+P/4rd/Dual-IVI so that port "N" from subscriber "A" is always mapped to public port "Z" on IPv4 address "Y". We could have the CPE know about that fixed mapping using the same DHCP options that A+P/4rd/ Dual-IVI would use, or use PCP, or use some other protocol. -d > 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf