Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Cameron Byrne [mailto:[e-mail]]
> Sent: Wednesday, September 28, 2011 8:16 AM
> To: Hui Deng
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Dan Wing
> Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt>
> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard
> 
> 
> On Sep 28, 2011 2:51 AM, "Hui Deng" <[e-mail]> wrote:
> >
> > Hi Dan,
> >
> > Inline please,
> >
> > 2011/9/27 Dan Wing <[e-mail]>
> >>
> >> > -----Original Message-----
> >> > From: Hui Deng [mailto:[e-mail]]
> >> > Sent: Monday, September 26, 2011 11:01 PM
> >> > To: Dan Wing
> >> > Cc: [e-mail]; [e-mail];
> >> > [e-mail]; [e-mail]; [e-mail]
> >> > 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.
> >
> > I don't see it matters
> 
> +1 ... since the alternative is that apps that require ipv4 sockets and
> pass ipv4 literals are stranded on ipv6 only networks.
> 
> Running code on the n900 shows that nat464 provides real user and
> network benefit

Can you run an FTP server on the BIH host, and have it do active mode
transfers and passive mode transfers?  I admit that isn't terribly 
important (nobody much loves FTP any more), but if the BIH host 
doesn't know its public mapping and can't create one, we lose that
class of applications that listen on a port.  Losing that class
of applications may, or may not, be important.  Many of those
applications do STUN or STUN-/ICE-like things for their own NAT
traversal (e.g., Skype).  But some don't and work properly 
without a hole punched (e.g., BitTorrent).

PCP can make all of this work, if it's integrated into BIH and
the NAT64.

-d



> Cb
> >>
> >>
> >> >       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: [e-mail] [mailto:behave-
> >> > [e-mail]] On
> >> >       > > Behalf Of ext Satoru Matsushima
> >> >       > > Sent: 13. syyskuuta 2011 06:51
> >> >       > > To: [e-mail]
> >> >       > > Cc: [e-mail]; 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
> >> >       > > > [e-mail] mailing lists by 2011-09-14.
> Exceptionally,
> >> > comments
> >> >       > may
> >> >       > > > be sent to [e-mail] 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
> >> >       > > > [e-mail]
> >> >       > > > https://www.ietf.org/mailman/listinfo/behave
> >> >       > >
> >> >       > > _______________________________________________
> >> >       > > Behave mailing list
> >> >       > > [e-mail]
> >> >       > > https://www.ietf.org/mailman/listinfo/behave
> >> >
> >> >       _______________________________________________
> >> >       Behave mailing list
> >> >       [e-mail]
> >> >       https://www.ietf.org/mailman/listinfo/behave
> >> >
> >> >
> >>
> >>
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ietf
> >
>