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

[Pekka Savola <pekkas@netcore.fi>]

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

On Fri, 12 Dec 2003, Brian E Carpenter wrote:
> General: 
> 
> 1) The document still needs quite a lot of work on (minor) errors in
> English and so on. I have not tackled this.

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

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

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

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.
 
> > 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:...] )

Seems sensible.

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

Agreed -- this would seem to make sense.
 
> > 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.

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 :-).

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

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