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

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Cameron Byrne [mailto:[e-mail]]
> Sent: Saturday, October 16, 2010 9:14 AM
> To: Dave Thaler
> Cc: [e-mail]; [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.

No, they appear to be dual-stack servers because the DNS64 still returns the
A record.  See draft-ietf-behave-dns64 section 5.3.3.

-Dave

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