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

[Hui Deng <[e-mail]>]

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

2009/10/12 Magnus Westerlund <[e-mail]>:
> 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
>
>
> Dan Wing skrev:
>>
>>
>>> -----Original Message-----
>>> From: bo zhou [mailto:[e-mail]]
>>> Sent: Wednesday, October 07, 2009 9:08 AM
>>> To: Dave Thaler; Dan Wing
>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>> Subject: Re: [BEHAVE] WG Review: Recharter of Behavior
>>> Engineering for Hindrance Avoidance (behave)
>>>
>>> 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?
>>
>> 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
>>> <[e-mail]> 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 ([e-mail])
>>> 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 <[e-mail]>
>>>         * Dave Thaler <[e-mail]>
>>>
>>>      Transport Area Director(s):
>>>
>>>         * Magnus Westerlund <[e-mail]>
>>>         * Lars Eggert <[e-mail]>
>>>
>>>      Transport Area Advisor:
>>>
>>>         * Magnus Westerlund <[e-mail]>
>>>
>>>      Mailing Lists:
>>>       General Discussion: [e-mail]
>>>       To Subscribe: [e-mail]
>>>       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
>>>      [e-mail]
>>>      https://www.ietf.org/mailman/listinfo/behave
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Bo Zhou
>>> China Mobile
>>>
>>>
>>
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>>
>
>
> --
>
> Magnus Westerlund
>
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave
>