-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
teemu(_dot_)savolainen(_at_)nokia(_dot_)com
Sent: Monday, September 26, 2011 8: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: [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(_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