Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave)

From: bo zhou <[email-masked]>
Date: Thu, 8 Oct 2009 00:07:33 +0800

Hi Dave and Dan,

I just found the charter of the Behave has been modified.

"5. An IPv6 network to an IPv4 network, i.e., perform translation between
IPv6 and IPv4 for packets in uni- or bi-directional flows that are
initiated from an IPv6 host towards an IPv4 host.  The translation
function is intended to service a specific IPv6 network of arbitrary
size and a specific IPv4 network of arbitrary size (neither of which are
the Internet)."

Does this cover host based translator solutions for 6 to 4?

Regards,

Bo Zhou

On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary <[email-masked]>wrote:

> A modified charter has been submitted for the Behavior Engineering for
> Hindrance Avoidance (behave) working group in the Transport Area of the
> IETF.  The IESG has not made any determination as yet.  The modified
> charter is provided below for informational purposes only.  Please send
> your comments to the IESG mailing list ([email-masked]) by Tuesday, October
> 6, 2009.
>
> Behavior Engineering for Hindrance Avoidance (behave)
> -----------------------------------------------------
> Current Status: Active Working Group
> Last Modified: 2009-09-09
>
> Current Status: Active Working Group
>
> Additional information is available at tools.ietf.org/wg/behave
> Chair(s):
>
>    * Dan Wing <[email-masked]>
>    * Dave Thaler <[email-masked]>
>
> Transport Area Director(s):
>
>    * Magnus Westerlund <[email-masked]>
>    * Lars Eggert <[email-masked]>
>
> Transport Area Advisor:
>
>    * Magnus Westerlund <[email-masked]>
>
> Mailing Lists:
>  General Discussion: [email-masked]
>  To Subscribe: [email-masked]
>  In Body: In Body: subscribe
>  Archive: http://www.ietf.org/mail-archive/web/behave
>
> Description of Working Group:
>
> The behavior of NATs varies from one implementation to another. As a
> result it is very difficult for applications to predict or discover the
> behavior of these devices. Predicting and/or discovering the behavior
> of NATs is important for designing application protocols and NAT
> traversal techniques that work reliably in existing networks. This
> situation is especially problematic for end-to-end applications where
> one or both end-points are behind a NAT, such as multiuser games,
> interactive multimedia and P2P download.
>
> The working group documents best current practices to enable NATs to
> function in as deterministic a fashion as possible. The NAT behavior
> practices will be application independent. This has already completed
> for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any
> additional protocol deemed necessary to handle. The WG has documented
> approaches for characterizing and testing NAT devices.
>
> BEHAVE will develop protocol-independent toolkits usable by application
> protocols for NAT traversal. The WG has already produced an update of
> the binding discovery protocol STUN. It will now produce a relay
> protocol that focuses on security and is usable with both IPv4 and
> IPv6, and capable of relaying between the two IP versions.
>
> Due to the WG's experience with translators and their behavior it has
> been given the following tasks to help encourage migration to IPv6. To
> support deployments where communicating hosts require using different
> address families (IPv4 or IPv6), address family translation is
> needed to establish communication. In BEHAVE's specification work on
> this topic it will coordinate with the V6ops WG on requirements and
> operational considerations.
>
> "An IPv4 network" or "an IPv6 network" in the descriptions below refer
> to a network with a clearly identifiable administrative domain (e.g.,
> an enterprise campus network, a mobile operator's cellular network, a
> residential subscriber network, etc.). It will also be that network
> that deploys the necessary equipment for translation.
>
> The BEHAVE WG will design solutions for the following six translation
> scenarios; other scenarios are out of scope:
>
> 1. An IPv6 network to IPv4 Internet, i.e. perform translation between
> IPv4 and IPv6 for packets in uni- or bi-directional flows that are
> initiated from an IPv6 host towards an IPv4 host. The translator
> function is intended to service a specific IPv6 network of arbitary
> size. Port translation is necessary on the IPv4 side for efficient IPv4
> address usage.
>
> 2. IPv6 Internet to an IPv4 network, i.e. perform translation between
> IPv4 and IPv6 for packets in uni- or bi-directional flows that are
> initiated from an IPv6 host towards an IPv4 host. The translator
> function is intended to service a specific IPv4 network using either
> private or public IPv4 addresses. This scenario has different
> constraints compared to (1), e.g. the IPv4 hosts that are to be
> reachable over IPv6 can be enumerated. Therefore, the WG should attempt
> to design a simpler solution with less impact on applications.
>
> 3. An IPv4 network to IPv6 Internet, i.e. perform translation between
> IPv4 and IPv6 for packets in uni- or bi-directional flows that are
> initiated from an IPv4 host towards an IPv6 host. The translator
> function is intended to service a specific IPv4 network using either
> public or private IPv4 address space.
>
> 4. IPv4 Internet to an IPv6 network, i.e. perform translation between
> IPv4 and IPv6 for packets in uni- or bi-directional flows that are
> initiated from an IPv4 host towards an IPv6 host. The translator
> function is intended to service a specific IPv6 network where selected
> IPv6 hosts and services are to be reachable.
>
> 5. An IPv6 network to an IPv4 network, i.e., perform translation between
> IPv6 and IPv4 for packets in uni- or bi-directional flows that are
> initiated from an IPv6 host towards an IPv4 host.  The translation
> function is intended to service a specific IPv6 network of arbitrary
> size and a specific IPv4 network of arbitrary size (neither of which are
> the Internet).
>
> 6. An IPv4 network to an IPv6 network, i.e., perform translation between
> IPv4 and IPv6 for packets in uni- or bi-directional flows that are
> initiated from an IPv4 host towards an IPv6 host.  The translation
> function is intended to service a specific IPv6 network of arbitrary
> size and a specific IPv4 network of arbitrary size (neither of which are
> the Internet).
>
> All translation solutions shall be capable of handling flows using TCP,
> UDP, DCCP, and SCTP, unless they prevent a timely completion of the
> work item. The parts of ICMP that can be translated are also required
> to work across a translation solution.  Additional protocols directly
> on top of IP may be supported. Translation mechanisms must handle IP
> fragmentation.
>
> The translators should support multicast traffic and its control
> traffic (IGMP and MLD) across them, both Single Source Multicast (SSM)
> and Any Source Multicast (ASM). However, the WG may determine that it
> becomes too complex or too difficult to realize with maintained
> functionality, for some or all cases of multicast functionality.
>
> Translation mechanisms cannot transparently support protocols that
> embed network addresses within their protocol messages without
> application level gateways (ALGs). Because ALGs have security issues
> (like blocking usage of TLS), are error prone and brittle, and hinder
> application development, the usage of ALGs in the defined translators
> should be avoided. Instead application developers will need to be aware
> and use mechanisms that handle the address family translation. ALGs may
> be considered only for the most crucial of legacy applications.
>
> DNS is a crucial part in making a large number of applications work
> across a translator. Thus the solution to the above translation cases
> shall include recommendations for DNS. If additional DNS functionality
> is needed, it may be developed. Any DNS extensions must be developed
> together with the DNSEXT WG, including issuing a joint WG last call for
> any documents.
>
> The WG needs to determine the best method for providing address space
> to a translator in the different deployment cases and documenting the
> pros and cons of the suggested approaches. The WG is to seek input from
> the Routing, Operations and Internet areas.
>
> Solutions may solve more than one of the cases, however timely delivery
> is more important than a unified solution.
>
> Goals and Milestones:
>
> Done      Submit BCP that defines unicast UDP behavioral requirements
> for NATs to IESG
> Done      Submit a BCP that defines TCP behavioral requireents for NATs
> to IESG
> Done      Submit a BCP that defines ICMP behavioral requirements for
> NATs to IESG
> Done      Submit informational that discusses current NAT traversal
> techniques used by applications
> Done      Submit BCP that defines multicast UDP
> Done      Submit revision of RFC 3489 to IESG behavioral requirements for
> NATs to IESG
> Done      Submit informational document for rfc3489bis test vectors
> Done      Submit experimental document that describes how an application
> can determine the type of NAT it is behind
> Done      Submit BCP document for DCCP NAT behavior
> Dec 2009  Submit to IESG: SCTP NAT behavior (BCP)
> Done      Submit to IESG: relay protocol (std)
> Done      Determine relative prioritization of the four translation
> cases. Documented in IETF74 minutes.
> Sep 2009  Submit to IESG: relaying of a TCP bytestream (std)
> Dec 2009  Submit to IESG: IPv6 relay protocol (std)
> Done      Determine what solutions(s) and components are needed to solve
> each of the four cases. Create new milestones for the solution(s) and
> the components. Documented in IETF74 minutes.
> Done      Submit to IESG:  TURN-URI document (std)
> Dec 2009  Submit to IESG:  framework for IPv6/IPv4 translation (info)
> Dec 2009  Submit to IESG:  stateless IPv6/IPv4 translation (std)
> Dec 2009  Submit to IESG:  stateful IPv6/IPv4 translation (std)
> Dec 2009  Submit to IESG:  DNS rewriting for IPv6/IPv4 translation (std)
> Jan 2010  Submit to IESG:  FTP ALG for IPv6/IPv4 translation (std)
> Jan 2010  Submit to IESG:  IPv6 prefix for IPv6/IPv4 translator (std)
> Mar 2010  Submit to IESG:  large scale NAT requirements (BCP)
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

-- 
Regards,

Bo Zhou
China Mobile

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Oct 2009 10:43:01 -0700

> -----Original Message-----
> From: bo zhou [mailto:[email-masked]] 
> Sent: Wednesday, October 07, 2009 9:08 AM
> To: Dave Thaler; Dan Wing
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior 
> Engineering for Hindrance Avoidance (behave)
> 
> Hi Dave and Dan,
>  

Yes, the "specific IPv6 network of arbitrary size" is a network containing 1
host.

-d

> Regards,
>  
> Bo Zhou
> 
> 
> On Wed, Sep 30, 2009 at 12:30 AM, IESG Secretary 
> <[email-masked]> wrote:
> 
>

---

From: bo zhou <[email-masked]>
Date: Thu, 8 Oct 2009 09:19:20 +0800

Hi Dan,

Thank you for your confirmation.

Regards,

Bo Zhou

-- 
Regards,

Bo Zhou
China Mobile

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 Oct 2009 13:46:40 +0200

Hi,

I just want to indicate that this was not my interpretation of the
charter. Case 5 and 6 was to my knowledge added to handle the cases when
two different businesses or different parts of the same organization
want to connect their networks together and need translation, rather
than going through the Internet.

When it comes to host based translation, I think we would need more
discussion about the motivation for that use case are. As I understand
it it is a case of handling IPv4 only legacy applications when you have
updated the operating system and uses an IPv6 only network. I don't see
any reason for doing it for IPv6 only applications as they should be
capable of handling IPv4 connectivity. And if an application really
needs IPv6 to function there exist tunneling solutions that would be a
better gap-filler than a translation based solution.

So for host based solutions I think we haven't had a conclusive
discussion about either what the requirements and motivations are or if
there is consensus to take that on.

Regards

Magnus Westerlund

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 12 Oct 2009 08:54:26 -0700

> there is consensus to take that on.

Agreed.  I really struggle to understand the need for host based
solutions.  The host based solutions are essentially a greenfield
build since it requires the host to ultimately be IPv6 and have the
PNAT software extensions.  It seems wiser to me, if you assume a new
host software is required, to go straight IPv6 with DNS64 / NAT64 as
an interworking technology that has a known exit strategy (reaching
the goal of IPv6 end-to-end) and has incentives for both the network
operator and the content owners to move towards end-to-end IPv6.  For
network operators, less NAT state is less cost so they want native
IPv6 ASAP.  For content owners and application developers, they want
to ensure their content is delivered inline with the end-to-end
principles to give the user the best experience.  In this way, NAT64 /
DNS64 allows me to keep growing my network with a steady-state service
model (NAT44 -- it is common in mobile today, and CGN will make it
common in fixed line) and provides rewards to content owners and
network operators to solve the chicken and egg problem that is IPv6
adoptions.

Much of the calls for host based NAT are fueled by fear of legacy IPv4
applications, but my users mostly use common protocols for Web and
Email that works well natively in IPv6 and through translators. A very
small portion of my users use applications that have no path to IPv6
native or NAT64, and they can be kept as IPv4 in the medium term.  I
cannot architect my future network based on 1% of users and their
legacy needs.

The only clear reason i can see to do host based IPv6 to IPv4
interworking is if the economics are such that transferring the
complexity of the translation from the network to the host is in
someway advantageous.  In my world of North American mobile wireless,
the service provider subsidizes the handset and therefore as the
service provider we have a large amount of control over which handsets
are used and we are responsible for supporting those handsets.  And,
we have a large degree of ownership of the architecture and complexity
in the network (which includes the devices attached to the network).
It behooves us to choose solutions that are end-to-end less complex
and easier to support in the long run, not simply transferring the
complexity to the handset vendors.  That said, network operators can
deploy what makes sense for their unique economic and technology
context, and IMHO NAT64 / DNS64 in the network is the best strategic
option, it has the right incentives towards end to end IPv6, and it is
only an incremental change to the NAT44 world of today.  Host based
solutions, IMHO,  are not being considered seriously in North America
or Europe.

Cameron Byrne
Principal Engineer
T-Mobile USA.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 Oct 2009 18:54:19 -0700

> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Monday, October 12, 2009 4:47 AM
> To: Dan Wing
> Cc: 'bo zhou'; 'Dave Thaler'; [email-masked]; [email-masked]

I agree we do not have consensus to adopt host-based translation.
But 6/4 translation is a function which could be done in a host or 
in a network device; I didn't intend any more meaning with my 
response.

-d

---

From: Zhen Cao <[email-masked]>
Date: Tue, 13 Oct 2009 11:15:51 +0800

On Mon, Oct 12, 2009 at 11:54 PM, Cameron Byrne <[email-masked]> wrote:
> PNAT software extensions.
Host based solutions are not greenfield considering BIS and BIA
solutions presence.

> It seems wiser to me, if you assume a new
Going to IPv6 is not straightforward, at least we need to update all
applications we are using. Comparatively, users can just install one
software while using host based solution.

> someway advantageous.  In my world of North American mobile wireless,

Not necessarily the only reason. First, Host based translation does
not resist network translation. Second, IETF has multiple solutions to
do IPv6 transition, it is hard to evaluate them from economic reasons.

> solutions, IMHO,  are not being considered seriously in North America

Do you have enough experience to say that for sure?

Thanks for discussion.

Regards

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 12 Oct 2009 23:12:22 -0700

> Host based solutions are not greenfield considering BIS and BIA

In my environment, doing a software upgrade on an existing device to
change the transport to achieve PNAT would be too risky to do on a
large scale.  Deploying anything with IPv6, for my environment, would
be a slow phased approach most likely incorporated into new devices
and services, not back-ported into existing devices and services.
Your environment may be different.  For me, any IPv6 will be
greenfield.

> software while using host based solution.

Which applications are you concerned about updating?  My users mostly
use web and email, and those clients are commonly available for IPv6
users today.  Which common applications are your users commonly using
that cannot use IPv6?

> do IPv6 transition, it is hard to evaluate them from economic reasons.

Hard, but the technology strategist at services providers will
generally be required to understand the options and the economics to
select the right solution.

> Do you have enough experience to say that for sure?

For North America, yes.  I worked on this 3G Americas paper with the
AT&T and Rogers, host based translation was never mentioned as an
option in any of the discussion during the production of the paper.

http://www.3gamericas.org/documents/2008_IPv6_transition_3GA_Mar2008.pdf

Verizon has a public spec available for their LTE devices, they are
IPv6 only with optional dual stack for IPv4.   No requirement for host
based translations.

Regarding Europe, T-Mobile entities are not considering PNAT.  I don't
personally have experience with other European operators.  But, i can
only officially speak for myself.  I have only seen one network
operator on this list or any list support host based translation.
That does not mean it will not be a standard or work well for that one
operator, it just means the solution has a narrow fit.

Thanks for the discussion,
Cameron

---

From: Zhen Cao <[email-masked]>
Date: Tue, 13 Oct 2009 15:10:05 +0800

On Tue, Oct 13, 2009 at 2:12 PM, Cameron Byrne <[email-masked]> wrote:
> greenfield

Host translation is not difficult to deploy according to our
experience. The header translation software is just a plug-in module
and easy to install for users.

> users today.  Which common applications are your users commonly using

Online games, video applications, anti-virus softwares, ftp, online
banking security plug-in, downloading, p2p-streaming, and any
softwares that are regularly updated from the internet.... I cannot
give an exhaustive list.

> http://www.3gamericas.org/documents/2008_IPv6_transition_3GA_Mar2008.pdf

We have come across too many such kind of whitepapers; few of them
actually flies. Maybe this one is different, but i do not know.
We only saw technologies fly away by one witnessed success and then
others followed the example.

> operator, it just means the solution has a narrow fit.

What's a narrow fit, count w.r.t operators or users? Europe has 0.3
billion users but >50 operators, while China Mobile has 0.5 billion
users.

---

From: Xing Li <[email-masked]>
Date: Wed, 14 Oct 2009 18:43:55 +0800

>> in a network device; I didn't intend any more meaning with my 

+1 xing

---

From: Hui Deng <[email-masked]>
Date: Wed, 14 Oct 2009 22:35:19 +0800

Hi, Magnus,

Thanks for your advice, we have many people working on the requirement
and motivation draft at the moment as you pointed out here,

Best regards,

-Hui

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Oct 2009 15:33:29 +0200

> and motivation draft at the moment as you pointed out here,

Great, looking forward to reading the document.

Best Regards

Magnus Westerlund