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

From: <[email-masked]>
Date: Mon, 26 Sep 2011 15:19:54 +0000

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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 26 Sep 2011 10:52:38 -0500

> *stateful* double translation  

That may be reasonable. And the document may reflect that.

> > >    NAT64 is NOT RECOMMENDED [RFC6180].		

One could suggest rephrasing that para with something like this -

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

> From: [email-masked] [mailto:[email-masked]]
On Behalf
> Of [email-masked]
> Sent: Monday, September 26, 2011 11:20 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 26 Sep 2011 17:29:25 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, September 26, 2011 8:20 AM
> Subject: RE: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt>
> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard
> 
> *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

---

From: Hui Deng <[email-masked]>
Date: Tue, 27 Sep 2011 13:49:34 +0800

May I know what's the reason to against stateful other than stateless?

-Hui

2011/9/26 Rajiv Asati (rajiva) <[email-masked]>

> recall

---

From: Hui Deng <[email-masked]>
Date: Tue, 27 Sep 2011 14:00:48 +0800

Hi Dan

inline please,

> mapping it will have on the Internet.  A+P mechanisms are
 Could you help be more elaboration on CPE can't determine the ampping?

> 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.

-Hui

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 27 Sep 2011 06:07:27 -0700

> From: Hui Deng [mailto:[email-masked]]
> Sent: Monday, September 26, 2011 11:01 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt>

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.

> which is align with 4rd  about 4v6 translation which has been
> contributed by major operators which is also align with NAT64
> deployment.

Sorry.

-d

> 	> changed so that also stateful double translation solutions are
> now ok
> 	> for
> 	> Unfortunately, I did not have chance to go to softwires
> interim, but
> 	> please
> 	> > Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-
> 06.txt>
> 	> (Dual
> 	> > >    utilizing double protocol translation.  Use of BIH
> together with
> 	> a
> 	> > This statement makes a strong obstacle when we develop
> stateless
> 	> solution
> 	> > I think that it is still remained a room to make decision
> whether
> 	> removing
> 	> the
> 	> > The discussion which we'll have in the softwires interim
> meeting
> 	> would be
> 	> > helpful to decide it.
> 	> >
> 	> > Best regards,
> 	> > --satoru
> 	> >
> 	> >
> 	> >
> 	> > > 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
> 	> > > [email-masked] mailing lists by 2011-09-14. Exceptionally,
> comments
> 	> may
> 	> > >   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
> 	> > >   synthesis of IPv4 addresses.  This draft obsoletes RFC
> 2767 and
> 	> RFC
> 	> > >   3338.
> 	> > >
> 	> > >
> 	> > >
> 	> > >

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 27 Sep 2011 06:10:16 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, September 26, 2011 11:14 PM
> To: [email-masked]; [email-masked]; [email-masked]
> 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).
> >
> I don't understand why that is significant enough factor for IETF to
> (not)
> recommend some double translation variants. I mean does existing
> applications work better if double translation is done in deterministic
> manner? 

Yes, it allows the CPE to implement an ALG -- if an application needs
an ALG (e.g., active-mode FTP).

-d

> One reasoning against double translation has been that it
> breaks
> some class of applications. Is it now so that some forms of double
> translation do not break applications while some others do?
> 
> 	Teemu
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 27 Sep 2011 07:57:30 -0700

> Sent: Tuesday, September 27, 2011 7:24 AM
> > > applications work better if double translation is done in
> > > deterministic manner?
> >
> an
> ALG
> > (e.g., active-mode FTP).
> Good point, but still in my eyes that does not count as too significant
> factor, as it is impossible to have a generic ALG and I've understood
> ALGs in CPEs are not very much desired?

Yes, it is impossible to build a successful 'generic' ALG which
fixes up all protocols.  ALGs need to be specific to each application
they're trying to 'fix'.

> So.. then.. is this sentence really still the IETF recommendation in
> the
> current state of affairs:
> --
>    utilizing double protocol translation.
> --

-d

---

From: <[email-masked]>
Date: Tue, 27 Sep 2011 06:13:53 +0000

> I believe the objection is against "non-deterministic translation", rather
than
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).
> 

I don't understand why that is significant enough factor for IETF to (not)
recommend some double translation variants. I mean does existing
applications work better if double translation is done in deterministic
manner? One reasoning against double translation has been that it breaks
some class of applications. Is it now so that some forms of double
translation do not break applications while some others do? 

	Teemu

---

From: <[email-masked]>
Date: Tue, 27 Sep 2011 14:23:35 +0000

> Yes, it allows the CPE to implement an ALG -- if an application needs an
ALG

Good point, but still in my eyes that does not count as too significant
factor, as it is impossible to have a generic ALG and I've understood ALGs
in CPEs are not very much desired?

So.. then.. is this sentence really still the IETF recommendation in the

	Teemu

---

From: Hui Deng <[email-masked]>
Date: Wed, 28 Sep 2011 17:50:57 +0800

Hi Dan,

Inline please,

2011/9/27 Dan Wing <[email-masked]>

> or ICMP packet from the subscriber.
I don't see it matters

---

From: Hui Deng <[email-masked]>
Date: Wed, 28 Sep 2011 17:51:53 +0800

inline please,

> an ALG (e.g., active-mode FTP).

Are you saying distrbiuted ALG is much better than centralized ALG?

-Hui

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 28 Sep 2011 08:16:00 -0700

>> or ICMP packet from the subscriber.

+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

Cb
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Sep 2011 08:48:40 -0700

> Sent: Wednesday, September 28, 2011 2:52 AM
> To: Dan Wing
> deterministic

Best is no ALG.  Worse is one ALG.  Even worse is two ALGs.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Sep 2011 08:58:34 -0700

> From: Cameron Byrne [mailto:[email-masked]]
> Sent: Wednesday, September 28, 2011 8:16 AM
> To: Hui Deng
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Dan Wing
> >> >       rather than stateful versus stateless.  By non-
> deterministic, I
> >> > mean
> +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

> >> >       traffic.  That is, it can function very much like
> A+P/4rd/Dual-
> >> > IVI
> >> >       > I would assume softwires follows these same IETF
> guidelines and
> >> >       > therefore is
> >> >       > now focusing solely on stateless approaches(?). If the
> IETF
> >> > opinion has
> >> >       > IETF, then that should perhaps be reflected in this
> document as
> >> > well.
> >> >       >
> >> >       > let us know if the discussions there impact also the
> quoted
> >> >       > recommendation.
> >> >       >
> >> >       > Best regards,
> >> >       >
> >> >       >       Teemu
> >> >       >
> >> >       > > > Hindrance Avoidance WG (behave) to consider the
> following
> >> > document:
> >> >       > > > be sent to [email-masked] instead. In either case,
> please
> >> > retain the
> >> >       > > >   translation mechanism that allows a class of IPv4-
> only
> >> >       > applications
> >> >       > > >   applications think they are talking with IPv4 peers
> by
> >> > local
> >> >       > > > No IPR declarations have been submitted directly on
> this I-
> >> > D.
> >> >       > > >
> >> >       > > >

---

From: Mark Townsley <[email-masked]>
Date: Wed, 28 Sep 2011 18:26:35 +0200

>> Running code on the n900 shows that nat464 provides real user and

Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/

- Mark

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 28 Sep 2011 11:12:08 -0700

> Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/

We're still doing that, and IPv6-only is still my philosophical
preference and that is how we are launching the IPv6 + NAT64/DNS64
service into the production mobile network (real soon now).  No change
in that path.

But some "power users" wanted their IPv4-only applications like Skype
to work so they coded a NAT46 work-around for the N900.  It is clever,
it works.

Their process of feeling the pain of a very few pesky IPv4-only apps
and working around it is all documented here:
http://talk.maemo.org/showthread.php?t=60320

Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D

In the end (as well as IPv6-only near term in mobile), IP version
agnostic apps will prove to be more reliable and therefore will get
more market share.

Cameron

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Sep 2011 14:21:20 -0400

> agnostic apps will prove to be more reliable and therefore will get

Not clear.   There's a tradeoff between the additional reliability of being version-agile, and the decreased reliability associated with hacks, proxies, relays, etc. needed to make the application work under NATted v4 at all.  That tradeoff will be different for different kinds of applications.

Keith

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 28 Sep 2011 12:14:04 -0700

On Wed, Sep 28, 2011 at 11:20 AM, Rajiv Asati (rajiva) <[email-masked]> wrote:
> Hi Cameron,
>
> Very interesting (& clever indeed).
>
>
> How does this clever code ensure that all but a few (pesky apps)
> continue to use IPv6 interface instead of the NAT46 interface?

Rajiv,

DNS64 is used.  So anything that can take  a AAAA will use a AAAA and
the native IPv6 path, with or without NAT64 -- as needed.

If the application itself delivers an IPv4 literal via protocols like
MSN or Skype, there is a path and socket made available, that is what
this NAT46 code does.

As i mentioned before, i don't like this.  But, i respect that it
works and it solves a real problem for users of these ipv4-only apps.
I personally find it easy to live with only IP version agnostic apps
that work well in an IPv6-only NAT64/DNS64 network.  I have been
eating this "dog food" for over 18 months.  I am happy to let the
market and eco-system punish apps for not supporting IPv6, and for the
market to reward apps that do support IPv6.

I believe draft-ietf-behave-v4v6-bih-06 has too narrow of a scope to
be useful since it explicitly does NOT support IPv4-only apps talking
to IPv4  servers over an IPv6-only network

Cameron

> Behalf Of
>> Cameron Byrne
>> Sent: Wednesday, September 28, 2011 2:12 PM
>> To: Mark Townsley
>> Cc: Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing
> (dwing)
>> Subject: Re: [BEHAVE] [Softwires] Last Call:
> <draft-ietf-behave-v4v6-bih-
>> 06.txt> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed
> Standard
>>
>> > Frankly, I preferred it when you were running IPv6-only without BIH
> on your
>> trial, providing pressure to get rid of all those stranded literals
> and
>> pushing apps to open ipv6 sockets :-/
>> >
>> > - Mark
>>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Sep 2011 08:50:57 -0700

> From: Rémi Després [mailto:[email-masked]]
> Sent: Thursday, September 29, 2011 5:14 AM
> To: Softwires-wg
> Cc: Dan Wing; Teemu Savolainen; Satoru Matsushima; IETF discussion
> list; Behave WG
> Subject: Re: [BEHAVE] ... Dual Stack Hosts Using "Bump-in-the-Host"
> (BIH))
> 
> Hi all,
> 
> Le 27 sept. 2011 à 21:10, Dan Wing a écrit :
> 
> ...
> >> I mean does existing
> +1
> As Softwire is concerned, it is worth noting here that, with
> encapsulation rather than double translation, NO ALG is ever needed.
> (Neither in ISP Border Relay nodes, nor in CPEs, nor in BIH hosts).

Do a message flow for active mode FTP with 4rd.  I did one, and
it needs an ALG in the 4rd NAPT44 function.

-d

> It is sometimes argued that double translation could be as simple than
> encapsulation.
> AFAIK, this discussion clearly indicates the contrary.
> (No ALGs eliminates any variants about where to put them.)
> 
> RD

---

From: GangChen <[email-masked]>
Date: Fri, 30 Sep 2011 00:09:08 +0800

Hello Dan,

> transfers and passive mode transfers?

Could you elaborate the scenario? You assume BIH host taking FTP sever.
I'm not sure whether following scenarios are correct

There are two possibilities

Option 1:

+---------------+
|BIH(FTP sever) |----------NAT64-------FTP Client
+---------------+

Option 2:

+---------------+
|BIH(FTP sever) |--------------FTP Client
+---------------+

In the case of Option 1, it can't work since NAT64 couldn't support
IPv4 initiated session

In the case of Option 2, it could work if BIH do ALG

BTW, if BIH takes the role of FTP client, I guess it works in both
active and passive mode when NAT64 do ALG

If there is something wrong, please correct me

Many thanks

Gang

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Sep 2011 09:28:09 -0700

> Sent: Thursday, September 29, 2011 3:13 AM
> To: Dan Wing
> Cc: 'Softwires-wg'; 'Behave WG'; 'IETF discussion list'; 'Teemu
> Savolainen'
> Le 29 sept. 2011 à 23:50, Dan Wing a écrit :
> 
> > Do a message flow for active mode FTP with 4rd.
> 
> Two cases (which I din't differentiate, sorry for that).
> a) The hosts handles 4rd
> b) The host is behind a NAT44 (
> 
> In case b), an ALG is needed as usual, as the CPE-NAT44 does its usual
> job for that.
> Case a) was assumed to apply to this discussion, considering a host
> that is directly the 4rd CE.
> 
> >  I did one, and
> In case a), the host can assign to an FTP application a pair of ports
> of its assigned range.
> Thus no translation is needed (e2e transparency).
> 
> OK?

If BIH worked that way, BIH would fail when the host has multiple
interfaces running, and those interfaces have different port
ranges.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Sep 2011 09:50:21 -0700

> Behalf Of GangChen
> Sent: Thursday, September 29, 2011 9:09 AM
> To: Dan Wing
> Cc: Hui Deng; [email-masked]; [email-masked]; [email-masked];
> Cameron Byrne
> Could you elaborate the scenario? 

The FTP server, using BIH, is an IPv4-only FTP server.  It
needs to listen on port 21 (the FTP control port), although if 
a URI is used to access the FTP server, an alternate control
port can work alright (ftp://ftp.example.com:12345).

For a passive-mode transfer, the FTP server only needs to know the
"PASV" command  (because that is all that's necessary for an IPv4 
FTP server; IPv4 FTP servers don't need to support EPSV and many 
on the Internet do not support EPSV).  Also for a passive-mode
transfer, the FTP client needs to initiate the TCP connections
to a port on the FTP server.

For an active-mode transfer, the FTP server connects back to
the client, using the IPv4 address indicated in the FTP
control channel.

> You assume BIH host taking FTP sever.

I agree it would fail with a passive-mode transfer.  But it should 
work with an active-mode transfer.

> In the case of Option 2, it could work if BIH do ALG

Yep.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Sep 2011 09:55:26 -0700

> If a host has several interfaces, each interface must have its own
> private IPv4 address (case b) at this interface), or its own IPv4
> address, possibly with a restricted port set (case a)).
> 
> The host must handle ports according to what applies to its chosen
> interface.

Agreed.  But it's not "the host", rather it is the application running
on the host that needs to have that awareness.  Said another way, it
cannot mindlessly bind to port 0, like applications do today -- but
has to bind to a free port on a specific interface.

> This isn't AFAIK specific of 4rd scenarios.

It is a problem common to all of the port-restricted scenarios if we move
the port restriction into the host (A+P, 4rd, dIVI).  Either the application
is aware of the port restriction (which is how you avoid an ALG in the host)
and require the application to change, or the application is unaware of the
port restriction (which means an ALG is necessary, for some applications, in
the host) but the application doesn't have to change.

So -- which way is the architecture going to go?  I have not seen this
written down anywhere.

-d

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 29 Sep 2011 09:56:00 -0700

On Thu, Sep 29, 2011 at 9:46 AM, Rajiv Asati (rajiva) <[email-masked]> wrote:
> Is there a dependency on the existence of IPv4 literal so as to use the v4-interface provided by NAT46 code? IOW, does every IP-only app work now on n900?
>
> Cheers,
> Rajiv

No, not "all" apps will work due to ALG dependencies associated with
NAT in general.  If the app does not work via NAT, it still will not
work.

What this code provides is the ability for IPv4-only apps on IPv6-only
networks to  work using their normal NAT traversal techniques + IPv4
literals .. this includes, Skype, MSN, and the ability to type
http://x.x.x.x into your browser.  There is no panacea, except making
the apps and services IPv6 native on IPv6 native networks, everything
else is a hack and time to market is important ipv4 exhausted.

Cameron

>> Sent: Wednesday, September 28, 2011 3:14 PM
>> To: Rajiv Asati (rajiva)
>> Cc: Mark Townsley; Hui Deng; Softwires-wg list; Behave WG; IETF Discussion;
>> Dan Wing (dwing)
>> Subject: Re: [BEHAVE] [Softwires] Last Call: <draft-ietf-behave-v4v6-bih-
>> 06.txt> (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard
>>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 28 Sep 2011 13:20:56 -0500

Hi Cameron,

Cheers,
Rajiv

Behalf Of
(dwing)
Standard
on your
and

---

From: Mark Townsley <[email-masked]>
Date: Wed, 28 Sep 2011 20:28:18 +0200

> to work so they coded a NAT46 work-around for the N900.  It is clever,

Ah, so it's not a model developed and (necessarily) supported by you. Thanks for the clarification. 

Yes, it makes sense that this would end up happening as the hosts evolve to what the network provides.

- Mark

---

From: Rémi Després <[email-masked]>
Date: Thu, 29 Sep 2011 20:57:14 +0800

Le 28 sept. 2011 à 23:16, Cameron Byrne a écrit :
...
> +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
> 

"So far so good" as result of an experiment, is per se a positive result, but it doesn't prove that there won't be problems in the future.

Running-code validation tests cannot be a reason to stop analyzing where problems might be likely to appear.

Regards,
RD

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 29 Sep 2011 11:46:25 -0500

Hi Cameron,

Cheers,
Rajiv

---

From: Hui Deng <[email-masked]>
Date: Fri, 30 Sep 2011 13:12:08 +0800

> -d
OK, I have see that there is two solutions for just one ALG.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Fri, 30 Sep 2011 13:16:53 +0800

inline please,

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

You are jumping into another discussion how to reach from outside,
There has other way to do it ,not just BIH+NAT64.

Hui

---

From: GangChen <[email-masked]>
Date: Fri, 30 Sep 2011 17:52:56 +0800

> work with an active-mode transfer.

In an active-mode transfer, IPv4 client needs initiate the TCP
connection to a port on the FTP sever in advance. Afterwards, FTP
server connects back to the client.
I'm not sure how could NAT64 support the first step (i.e. IPv4
initiated TCP connection)?

Many thanks

Gang

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 30 Sep 2011 09:05:29 -0700

> From: GangChen [mailto:[email-masked]]
> Sent: Friday, September 30, 2011 2:53 AM
> To: Dan Wing

Static mapping in the NAT64, for the FTP control channel (port
21 or an alternate port).  That could be done by the user's
profile (draft-cheng-behave-nat-fwd-port-radius-ext), PCP, or
a web portal that manages the NAT64's configuration.

-d