Subject: I-D ACTION:draft-ietf-v6ops-application-transition-00.txt

From: [email-masked]
Date: Wed, 10 Dec 2003 15:40:21 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: Application Aspects of IPv6 Transition
	Author(s)	: M. Shin
	Filename	: draft-ietf-v6ops-application-transition-00.txt
	Pages		: 27
	Date		: 2003-12-10
	
As IPv6 networks are deployed and the network transition discussed,
one should also consider how to enable IPv6 support in applications
running on IPv6 hosts, and what is the best strategy to develop IP
protocol support in applications.  This document specifies
scenarios and aspects of application transition. It also proposes
guidelines on how to develop IP version-independent applications
during the transition period.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-v6ops-application-transition-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-v6ops-application-transition-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Dec 2003 13:42:03 +0100

I have a couple of general comments and then some details.

General: 

1) The document still needs quite a lot of work on (minor) errors in
English and so on. I have not tackled this.

2) I think there is a need to "spam" people with experience in porting applications
for their comments on this draft.
Details:

> 2. Overview of IPv6 application transition
> 
>      The transition of an application can be classifed using four
>      different cases (excluding the first case when there is no IPv6
>      support either in the application or the operating system), as
>      follows:
> 
>       +-------------------+
>       |       appv4       | (appv4 - IPv4-only applications)
>       +-------------------+
>       |     TCP / UDP     | (transport protocols)
>       +-------------------+
>       |    IPv4 | IPv6    | (IP protocols supported/enabled in the OS)
>       +-------------------+
> 
>       Case 1. IPv4 applications in a dual-stack node

These days we have to consider SCTP, DCCP etc too.

> 5.1 Presentation format for an IP address

This section should refer to draft-main-ipaddr-text-rep-00.txt

It should also mention the different format defined in RFC 2821
(i.e. [IPv6:...] )

> 5.4.3 Storage of IP addresses
...
>      Instead of using IP addresses, applications should use FQDNs.
>      Hence, applications delegate the resolution of the IP addresses to
>      the name resolution system, which will return the associated IP
>      address at the moment of the query.

This makes it sound too easy. I think that in some contexts (such as
massive peer to peer systems, or highly dynamic networking) this is bad
advice. Even in normal situations, it may be appropriate to cache addresses
for a considerable time. I would rewrite as

  When possible, applications should store names, such as FQDNs, instead
  of storing addresses. In this case applications are only bound to specific
  addresses at run time, or for the duration of a cache lifetime. Other types 
  of application, such as massive peer to peer systems with their own  
  rendez-vous and discovery mechanisms, may need to cache addresses for 
  performance reasons, but cached addresses should not be treated as permanent, 
  reliable information. In highly dynamic networks any form of name resolution 
  may be impossible, and here again addresses must be cached.

> 7. Transition mechanism considerations
> 
>      A mechanism, [NAT-PT], introduces a special set of addresses,
>      formed of NAT-PT prefix and an IPv4 address; this refers to IPv4
>      addresses, translated by NAT-PT DNS-ALG.  In some cases, one might
>      be tempted to handle these differently.
> 
>      However, IPv6 applications must not be required to distinguish
>      "normal" and "NAT-PT translated" addresses (or any other kind of
>      special addresses, including the IPv6-mapped IPv4-addresses):  that
>      would be completely unscalable, and if such distinction must be
>      made, it must be done elsewhere (e.g. kernel, system libraries).

I'm not sure why it would be unscalable - messy, yes, but not unscalable.
Also, what if an application *wants* to treat a NAT-PT based session differently
(i.e. implement some legacy features because it knows that the other end
is IPv4)? Shouldn't the socket API be capable of telling the upper layer
"this address was translated"?

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Dec 2003 19:46:23 +0200 (EET)

Thanks for comments, Brian; more in-line -- responding as co-author..

> English and so on. I have not tackled this.

Yep..
 
> for their comments on this draft.

Agreed, if we could find fresh new forums to send this to.  
Suggestions are still welcome :-)

> These days we have to consider SCTP, DCCP etc too.

Agreed.  I think we should do the following:

1) replace "TCP / UDP" to "TCP / UDP / others" (or something like 
that).

2) contact SCTP and DCCP WGs or some knowledgeable folks to ping 
whether the document requires more extensive changes due to these 
protocols.  (If the changes were too extensive, we could also decree 
them out of scope, but that would remain to be seen.)

Myung-Ki, maybe you could try to do this as the editor?

3) do a little bit of review if some other whether some minor wording 
changes would be needed to take non-TCP/UDP cases in the consideration 
better.
 
> It should also mention the different format defined in RFC 2821

Seems sensible.

>   may be impossible, and here again addresses must be cached.

Agreed -- this would seem to make sense.
 
> I'm not sure why it would be unscalable - messy, yes, but not unscalable.

Maybe we're using different words to describe the same issue.  I call 
this unscalable because I do not want to see every application to 
implement it's own version of this (about 50% of them being probably 
incorrect or otherwise wrong :-).

> "this address was translated"?

Maybe yes, but the point is that APIs do not provide these *today*.  
If they did, I don't think there would be all that many problems
having something like this implemented as part of APIs.  

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings