Subject: [BEHAVE] Comments on draft-baker-behave-v4v6-framework-02

From: Dave Thaler <[email-masked]>
Date: Tue, 14 Apr 2009 13:21:00 -0700

I was out on jury duty last week so am still trying to catch up on email,
but I did have a chance to review the framework document and type up
my comments.  There's a lot of them so they're inline in the attached
PDF.

In addition, I have a couple of general comments:

The definition of "IPv{4,6}-only" talks about "two application
instances are capable of communicating using IPv{4,6}...", and
the title of the document is Framework for IPv4/IPv6 Translation.
This is all well and good, except that in reading it this time I realized
the document today doesn't actually cover all of that.  Specifically
what is missing is cases where there's an IPv{4,6}-only application
running on a dual-stack (i.e. completely provisioned) host.  Section 1.5
talks about connecting IPv{4,6} "networks".  This is sufficient only
so long as you could define a single application instance as a "network"
which seems a bit unintuitive.

In my view, the framework really should be an overall framework for
talking about the problems.  Doing translation in a host, for example,
should be within the scope of the framework.

Some relevant RFCs (not saying these *solutions* need to be explained
in the framework but they address scenarios, where the *scenario(s)*
should be covered in the framework) are:
 * RFC 2767 (Bump in the Stack)
 * RFC 3338 (Bump in the API)
 * RFC 3493's use of V4MAPPED addresses
 * RFC 3142 (a TCP/UDP relay)

For example, if you have an IPv4-application listening for incoming
connections, on a node that has both IPv4 and IPv6 provisioned,
and IPv4 and IPv6 addresses in DNS, then how can a client in an
IPv6-only network talk to it?  (There could be a translator in
the dual stack host, or a TDP/UDP relay, or the DNS ALG might
synthesize AAAA records even though there's a real AAAA record
- I brought this to the attention of the DNS64 draft authors in
separate email.)  Currently this scenario isn't even mentioned,
but should be, in my view.

-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Apr 2009 15:13:18 +1200

Dave,

> should be within the scope of the framework.

I understood that the AD's guidance was to limit the scenarios
to the separate-translator-box cases that the draft covers. Won't we
complicate the discussion enormously by expanding the scope as you
describe?

    Brian
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 16 Apr 2009 14:42:23 -0700

> -----Original Message-----
> From: Dave Thaler [mailto:[email-masked]]
> Sent: Tuesday, April 14, 2009 1:21 PM
> To: Fred Baker; Xing Li; congxiao
> Cc: Behave WG
> Subject: [BEHAVE] Comments on draft-baker-behave-v4v6-framework-02
> 

I have to give this a +1. Using end-system-specific
translators (e.g., RFC2767) instead of in-the-network
translators would eliminate exposure to path MTU and
fragmentation issues such as Iljitsch and others have
been concerned about.

Thanks - Fred
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Apr 2009 11:40:17 -0400

Fred, maybe you want to push the end-system-specific model in a  
separate draft. We are working on an in-network model, and going into  
scenarios that are not in-network will complicate things dramatically.

And I have to ask, why would the end system translate? Why would it  
not simply deploy natively? The point here is that you have an end  
system that will happily use whatever the network provides, but the  
network provision is IPv4 or IPv6 but not both.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 17 Apr 2009 15:39:21 -0700

Fred:

> From: Fred Baker [mailto:[email-masked]]
> Sent: Friday, April 17, 2009 8:40 AM
> To: Templin, Fred L
> Cc: Dave Thaler; Xing Li; congxiao; Behave WG
> Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-framework-02
> 
> not simply deploy natively?

Deploy natively, sure - but, translate to accommodate
legacy apps if necessary.

> The point here is that you have an end

Why not both?

Fred
 
> >> running on a dual-stack (i.e. completely provisioned) host.
Section
> > 1.5

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Apr 2009 11:20:33 +0200

> complicate the discussion enormously by expanding the scope as you

I think the further discussion indicates that it is likely complicating
things. So far all discussion has been focused on the in the network
translator model. I am not against separate documents discussing this
use case, but lets try to avoid feature creep that results in extra delay.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
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: "Templin, Fred L" <[email-masked]>
Date: Mon, 20 Apr 2009 10:18:35 -0700

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, April 20, 2009 2:21 AM
> To: Brian E Carpenter
> Cc: Xing Li; congxiao; Behave WG; Fred Baker; Dave Thaler
> things.

I don't understand that; translation in the host avoids
factors exacerbated by in-the-network translation such as
path MTU, fragmentation, ICMP black-holing, transport-
specific checksum conversion, etc. How would discussing
the in-the-host use case scenario complicate things?

Fred

> So far all discussion has been focused on the in the network

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Apr 2009 14:04:27 +0200

> the in-the-host use case scenario complicate things?

I might not have been clear. Yes, from a technical stand point is has
its merits with some specific limitations on when it is possible  to use
and the issue with deployment.

>From a standardization work point is does complicate things. I am fine
with some overview positioning of the solution in respect to the network
based solutions. However, it is additional work for a use case that
until now has not been discussed. Unless there is a clear consensus that
this should be done with equal or higher priority than what is already
being worked on I do suggest that we put it on substantial lower priority.

Cheers

Magnus Westerlund