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

[Brian E Carpenter <brc@zurich.ibm.com>]

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