Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

[<[e-mail]>]

Hi,

That's what I and some others tried to say as well:) Use IPv6 for the traffic needing special handling and put the rest in IPv4-in-IPv6.

Anyhow, lots of emails for this Saturday. I will try to fetch the key themes out of all these emails and do -01 by mid next week.

Best regards,

Teemu
________________________________________
From: ext Brian E Carpenter [[e-mail]]
Sent: Saturday, October 16, 2010 11:28 PM
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

Hi Teemu,

On 2010-10-17 08:41, [e-mail] wrote:
> The consensus was formed after NAT64 was finalized?-)
>
> I read the charter's "IPv6-only" as "effectively IPv6-only from the BIH-enabled node point of view".
>
> Like I said, it would make it easier to edit the document if I would understand why it is better for IPv4-only browser to fail than connect through BIH, using IPv6, to dual-stack enabled web server (in a scenario where the BIH enabled host just does not have IPV4-connectivity). I can of course edit strict text in, but knowing why would make it more fun.
>
> The header overhead is not a real problem, and AFAIK ROHC does compress IP-in-IP tunnel headers away just fine (from the most resource constrained link). The problem is that the policy and charging control, QoS, and about everything is based on assumption that various decisions can be made based on the outermost header.

So what? All that means is that a client that chooses to tunnel gets
best effort service inside the tunnel, and the operator still gets to
apply its policy, charging and QOS to the packets that it sees.
Let's make BIH work for the case it's good for.

   Brian

> Best regards,
>
> Teemu
>
> ________________________________________
> From: ext Dave Thaler [[e-mail]]
> Sent: Saturday, October 16, 2010 10:20 PM
> To: Savolainen Teemu (Nokia-MS/Tampere)
> Cc: [e-mail]; [e-mail]
> Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Saturday, October 16, 2010 12:15 PM
>> To: Dave Thaler
>> Cc: [e-mail]; [e-mail]
>> Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt
>>
>> Hi,
>>
>> Cellular network operators (as a community) have systematically rejected host
>> based tunneling solutions, e.g. DS-Lite. The traffic must go native.
>
> It's unfortunate that operators have rejected solutions that work for all applications
> (translation doesn't).  The current IETF consensus is to only standardize such
> solutions.   You're welcome to try to change that consensus, but right now
> our WG constrains what we can do in this WG.
>
> As I stated during the rechartering discussion, it appears that such operators would
> need a tunneling-with-header-compression scheme that doesn't currently exist,
> but that would presumably belong in softwires rather than behave.
>
> -Dave
>
>> At least several do like IPv6-only with NAT64, though. Maybe more in the future
>> as transition progresses.
>>
>> Now BIH could make an IPv4-only application running on a host in said
>> IPv6/NAT64 network contact the content server over IPv6.
>>
>> As it happens, different instances of the same IPv4-only application may be
>> running on other hosts that may be in IPv4-only networks.
>>
>> Now the content server is in trouble, as if it is IPv4-only it cannot provide
>> content for application instances running on hosts in IPv6/NAT64 accesses
>> (NAT464 not allowed - this I understand). Switching to IPv6-only provides
>> content for application instances in hosts in IPv6/NAT64 networks, but now apps
>> in IPv4-only accesses are left in cold (the network operators of "legacy" IPv4-
>> only networks unlikely install NAT46s very soon). Dual-stack operation of
>> content server would make everyone happy, but that does not happen to be
>> allowed (and I don't understand why this is not allowed).
>>
>> Best regards,
>>
>> Teemu
>>
>>
>> ________________________________________
>> From: ext Dave Thaler [[e-mail]]
>> Sent: Saturday, October 16, 2010 9:16 PM
>> To: Savolainen Teemu (Nokia-MS/Tampere)
>> Cc: [e-mail]; [e-mail]
>> Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>> Sent: Saturday, October 16, 2010 10:21 AM
>>> To: [e-mail]; Dave Thaler
>>> Cc: [e-mail]
>>> Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt
>>>
>>> So are you essentially saying the BIH module should spend explicit
>>> effort to determine it is running in the desired scenario?
>>>
>>> 1) Test whether A record exist in addition to AAAA and if yes give an
>>> error to app. IPv4-only app would be allowed to talk only to server
>>> that has only AAAA record.
>> No, getaddrinfo() would return a failure only if the host has no IPv4 connectivity,
>> AND the AI_ADDRCONFIG flag was set by the caller.  See RFC 3493 section 6.1.
>> Note it doesn't say anything about the behavior of gethostbyname() so an
>> implementation would have to choose whether that function logically has
>> AI_ADDRCONFIG set or not.
>>
>>> Communication to dual-stack enabled servers would be not allowed -
>>> even if host has only IPv6 connectivity...
>> Not quite.  Communication would not be allowed *via BIH*.
>> Communication may still be allowed via some other mechanism, e.g., DS-lite.
>> But that's not the job of the doc in this WG.
>>
>>> 2) Test whether the received AAAA record is actually synthesized and
>>> if yes, give an error to app. (Synthesized AAAA means there is A
>>> record in existence, even if for any reason was not received by BIH).
>> This one doesn't seem necessary to me.
>>
>> -Dave
>>
>>> But why? Wouldn't the communications fail anyway if the app is not of
>>> the supported class (e.g. an app that requires ALG)?
>>>
>>> Shouldn't the BIH component just make the best effort attempt of
>>> IPv4->IPv6 translation, send the packet out, and then see if the
>>> network can actually deliver?
>>>
>>> Best regards,
>>>
>>> Teemu
>>>
>>> ________________________________________
>>> From: ext Cameron Byrne [[e-mail]]
>>> Sent: Saturday, October 16, 2010 7:14 PM
>>> To: Dave Thaler
>>> Cc: Savolainen Teemu (Nokia-MS/Tampere); [e-mail]
>>> Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt
>>>
>>> On Sat, Oct 16, 2010 at 8:18 AM, Dave Thaler <[e-mail]>
>> wrote:
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>> Behalf Of [e-mail]
>>>>> Sent: Friday, October 15, 2010 11:48 PM
>>>>> To: [e-mail]
>>>>> Cc: [e-mail]; [e-mail]
>>>>> Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt
>>>>>
>>>>> Hi Jan, all,
>>>>>
>>>>> What I'm bit hesitant is to add lots of system architecture
>>>>> considerations into this document. I would like to keep BIH
>>>>> document small and to describe just a component behavior and what
>>>>> it can and cannot do (e.g. ALG issues). Then architecture
>>>>> descriptions, be it node design, 3GPP, WiMAX, BBF, whatever, use or
>>>>> don't use components to
>>> build systems.
>>>>> After all, there are no disclaimers in DS-Lite, 6a44, 6RD, 6to4,
>>>>> Teredo etc that they are not applicable in those networks that do
>>>>> not allow tunneling because of difficulties tunneling causes for
>>>>> policy and
>>> charging control systems..
>>>>> But of course we work based on WG consensus:) Hence I try to
>>>>> clarify this a bit as it seems to be WG desire.
>>>>>
>>>>> One question for you, though: if both ends are dual-stack, access
>>>>> network (or some segment) is IPv6-only and tunneling services are
>>>>> not provided for hosts: do you think BIH should be used to provide
>>>>> some connectivity, or rather have no connectivity at all? For me it
>>>>> sounds difficult to mandate deployment of IPv4-
>>>>> over-IPv6 tunneling endpoint capability to all servers, and there
>>>>> are access networks that refuse to provide tunneling due PCC issues.
>>>> Our current charter page states this:
>>>>
>>>>> * An IPv4 application running on an IPv6-only connected host to the
>>>>>  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 embedded
>>>>> in the IPv4 host
>>>> And
>>>>
>>>>> Apr 2011 Submit to IESG: host-based NAT46 translation for IPv4-only
>>>>> applications to access IPv6-only servers (std)
>>>> Note that it states "IPv6-only servers" and "to the IPv6 Internet".
>>>>
>>>> If the destination is IPv4 capable (A record returned by DNS), then that's
>>>> out of scope of this milestone and charter item.   Hence the WG draft
>>>> should not attempt to solve this case, as the IETF will not do a
>>>> standards track solution for this per our current charter.  Any such
>>>> discussion should be in a separate non-WG draft.
>>> I agree with others that say the draft should explicitly address this
>>> case in question.
>>>
>>> To the BIH host, real IPv4-only servers appear to be IPv6-only via the NAT64.
>>>
>>> Cameron
>>>
>>>> -Dave
>>>>
>>>>> Best regards,
>>>>>
>>>>> Teemu
>>>>>
>>>>>
>>>>> ________________________________________
>>>>> From: ext Jan Melen [[e-mail]]
>>>>> Sent: Saturday, October 16, 2010 9:21 AM
>>>>> To: Savolainen Teemu (Nokia-MS/Tampere)
>>>>> Cc: [e-mail]; [e-mail]
>>>>> Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt
>>>>>
>>>>> Hi Teemu,
>>>>>
>>>>> I think that the introduction needs to elaborate a bit of scoping
>>>>> (to be more
>>>>> strict) where the BIH is applicable. Currently the introduction
>>>>> IMHO doesn't discuss enough of the applicability and thus you
>>>>> should add there something in the lines that BIH should not be used
>>>>> when both peers are dual-stacked or both peers are supporting the
>>>>> same address family even if there is network segments that have
>>>>> different address families in between. BIH is only applicable for
>>>>> scenarios where IPv4-only application contacts a IPv6-only server
>>>>> with end-to- end IPv6-
>>> connectivity.
>>>>> Additionally you might consider adding some pointers for the reader
>>>>> to look in to tunneling solutions when it comes to delivering IPvX
>>>>> over IPvY networks to IPvX host.
>>>>>
>>>>>   Regards,
>>>>>       Jan
>>>>>
>>>>> On Oct 15, 2010, at 11:47 PM, <[e-mail]>
>>>>> <[e-mail]> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The goal of BIH is that an IPv4-only application that does not
>>>>>> require ALG can
>>>>> be made to talk to a server reachable only over IPv6.
>>>>>> Hence the BIH would be used in IPv6-only access or in dual-stack
>>>>>> access if the
>>>>> server is not reachable via IPv4.
>>>>>> If the application is IPv4-only, host is on dual-stack or
>>>>>> IPv4-only access, and
>>>>> server is dual-stack or IPv4-only reachable, then BIH is not used.
>>>>> This is case 1 of the following table:
>>>>>> --
>>>>>>          Mapping table | Access    | Peer   | Created
>>>>>>          entry for     |link type  | support| address mapping
>>>>>>       -------------------+-------------+-------------------------------
>>>>>>       (1) real IPv4    |IPv4 or DS | v4     | < no mapping needed >
>>>>>>       (2) real IPv6    |IPv6 or DS | v6     | < no mapping needed >
>>>>>>       (3) real IPv4    |IPv6       | v4 & v6| real IPv4 -> real IPv6
>>>>>>       (4) real IPv6    |IPv4       | v4 & v6| < out of scope >
>>>>>>       (5) local IPv4   |IPv6 or DS | v6     | local IPv4 -> real IPv6
>>>>>>       (6) local IPv6   |IPv4 or DS | v4     | < out of scope >
>>>>>>       (7) real IPv4    |IPv6       | v4     | < out of scope >
>>>>>>       (8) real IPv6    |IPv4       | v6     | < out of scope >
>>>>>> --
>>>>>>
>>>>>> I'll look if this could be clarified for -01.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Teemu
>>>>>> ________________________________________
>>>>>> From: [e-mail] [[e-mail]] On Behalf
>>>>>> Of ext Ed Jankiewicz [[e-mail]]
>>>>>> Sent: Friday, October 15, 2010 11:17 PM
>>>>>> To: [e-mail]
>>>>>> Subject: Re: [BEHAVE] I-D
>>>>>> Action:draft-ietf-behave-v4v6-bih-00.txt
>>>>>>
>>>>>>  I had passed Teemu an abandoned draft about a translator I
>>>>>> worked on about 5 years ago.  It was similar to the BIH, although
>>>>>> in an external box rather than on host, the draft called this
>>>>>> Bump-in-the-Wire
>>> (BIW).
>>>>>> We felt that IPv4 pass-through was an essential feature to avoid
>>>>>> such double translation.  We assumed native routing of the IPv4
>>>>>> packets through a dual-stack network, but encapsulation would be
>>>>>> needed if the host has only an IPv6 address.
>>>>>>
>>>>>> Should BIH include an IPv4 pass-through?
>>>>>>
>>>>>>
>>>>>> On 10/15/2010 2:44 PM, Laganier, Julien wrote:
>>>>>>> Folks,
>>>>>>>
>>>>>>> A document on IPv6 transition [1] I was reading proposes to
>>>>>>> combine BIH
>>>>> with NAT64 to support IPv4 applications on an IPv6 only host
>>>>> connecting to an
>>>>> IPv4 server as follows: "The BIH in the host translates the IPv4
>>>>> application's packets into IPv6 and the NAT64 translates IPv6
>>>>> packets into IPv4 and vice versa."
>>>>>>> This is an example of double NAT46 and NAT64 translation that I
>>>>>>> thought we
>>>>> were not recommending neither working on -- the BIH work item is
>>>>> supposed to fulfill the following scenario:
>>>>>>>   * An IPv4 application running on an IPv6-only connected host to the
>>>>>>>   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 embedded
>>>>>>>   in the IPv4 host.
>>>>>>>
>>>>>>> Thus, wondering if we shouldn't add to the draft an
>>>>>>> applicability statement
>>>>> recommending against the use of BIH technologies together with
>>>>> NAT64 to support scenarios where an IPv4 application on an
>>>>> IPv6-only connected host talks to an IPv4 server, since I thought
>>>>> the recommended IETF approach to support such scenarios is
>>>>> encapsulation, as
>>> opposed to double translation.
>>>>>>> --julien
>>>>>>>
>>>>>>> [1]
>>>>>>> http://ftp.3gpp.org/tsg_sa/WG2_Arch/TSGS2_81_Prague/Docs/S2-
>>> 105121
>>>>>>> .zi
>>>>>>> p
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: [e-mail] [mailto:[e-mail]]
>>>>>>>> On Behalf Of [e-mail]
>>>>>>>> Sent: Monday, October 11, 2010 7:30 AM
>>>>>>>> To: [e-mail]
>>>>>>>> Cc: [e-mail]
>>>>>>>> Subject: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt
>>>>>>>>
>>>>>>>> A New Internet-Draft is available from the on-line
>>>>>>>> Internet-Drafts directories.
>>>>>>>> This draft is a work item of the Behavior Engineering for
>>>>>>>> Hindrance Avoidance Working Group of the IETF.
>>>>>>>>
>>>>>>>>
>>>>>>>>     Title           : Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
>>>>>>>>     Author(s)       : B. Huang, et al.
>>>>>>>>     Filename        : draft-ietf-behave-v4v6-bih-00.txt
>>>>>>>>     Pages           : 25
>>>>>>>>     Date            : 2010-10-11
>>>>>>>>
>>>>>>>> This document describes the "Bump-In-the-Host" (BIH), a host
>>>>>>>> based protocol translation mechanism that allows a subset of
>>>>>>>> applications supporting only one IP address family to
>>>>>>>> communicate with peers that are reachable or supporting only
>>>>>>>> the other address
>>> family.
>>>>>>>> This specification addresses scenarios where a host is provided
>>>>>>>> dual stack or IPv6 only network connectivity.  In the dual
>>>>>>>> stack network case, single address family applications in the
>>>>>>>> host sometime will communicate directly with other hosts using
>>>>>>>> the different address family.  In the case of IPv6 only network
>>>>>>>> or
>>>>>>>> IPv6 only destination,
>>>>>>>> IPv4 originated communications have to be translated into IPv6.
>>>>>>>> The BIH makes the IPv4 applications think they talk to IPv4
>>>>>>>> peers and hence hides the IPv6 from those applications.
>>>>>>>>
>>>>>>>> Acknowledgement of previous work
>>>>>>>>
>>>>>>>> This document is an update to and directly derivative from
>>>>>>>> Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI
>>>>>>>> [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim,
>>>>>>>> Alain Durand, and Erik Nordmark's [RFC3338], which similarly
>>>>>>>> provides a dual stack host means to communicate with other IPv6
>>>>>>>> host using existing IPv4
>>>>> appliations.
>>>>>>>> This document combines and updates both [RFC2767] and [RFC3338].
>>>>>>>>
>>>>>>>> The changes in this document reflect five components
>>>>>>>>
>>>>>>>>
>>>>>>>> 1.  Supporting IPv6 only network connections
>>>>>>>>
>>>>>>>>
>>>>>>>> 2.  IPv4 address pool use private address instead of the
>>>>>>>>
>>>>>>>> unassigned IPv4 addresses (0.0.0.1 - 0.0.0.255)
>>>>>>>>
>>>>>>>>
>>>>>>>> 3.  Extending ENR and address mapper to operate differently
>>>>>>>>
>>>>>>>>
>>>>>>>> 4.  Adding an alternative way to implement the ENR
>>>>>>>>
>>>>>>>> 5.  Going for standards track instead of experimental/
>>>>>>>>
>>>>>>>> informational
>>>>>>>>
>>>>>>>> A URL for this Internet-Draft is:
>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-
>>>>>>>> 00
>>>>>>>> .tx
>>>>>>>> t
>>>>>>>>
>>>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>>>
>>>>>>>> Below is the data which will enable a MIME compliant mail
>>>>>>>> reader implementation to automatically retrieve the ASCII
>>>>>>>> version of the Internet-Draft.
>>>>>>> _______________________________________________
>>>>>>> Behave mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/behave
>>>>>> --
>>>>>> Ed Jankiewicz - SRI International Fort Monmouth Branch Office -
>>>>>> IPv6 Research Supporting DISA Standards Engineering Branch
>>>>>> 732-389-1003 or  [e-mail]
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>> _______________________________________________
>>>> Behave mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/behave
>>>>
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave
>