-----Original Message-----
From: Hui Deng [mailto:denghui02(_at_)gmail(_dot_)com]
Sent: Monday, September 26, 2011 11:01 PM
To: Dan Wing
Cc: teemu(_dot_)savolainen(_at_)nokia(_dot_)com;
satoru(_dot_)matsushima(_at_)gmail(_dot_)com;
ietf(_at_)ietf(_dot_)org; 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
Hi Dan
inline please,
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
Could you help be more elaboration on CPE can't determine the ampping?
It can't determine the public IP address and port of a mapping on the
NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- because
the CGN is going to make a dynamic mapping when it sees a UDP, TCP,
or ICMP packet from the subscriber.
deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p).
By the way, I would say you are missing one early draft:
http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00
which is align with 4rd about 4v6 translation which has been
contributed by major operators which is also align with NAT64
deployment.
Sorry.
-d
-Hui
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
_______________________________________________
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