Subject: WG Last Call: draft-ietf-v6ops-application-transition-01.txt (fwd)

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Mar 2004 11:18:58 +0200 (EET)

(co-chair hat on)

Just a reminder -- the WGLC for the application transition document 
was issued just prior to the IETF, and still runs for about a week or 
so.  Please provide feedback.  Thanks!

---------- Forwarded message ----------
Date: Fri, 27 Feb 2004 11:19:38 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Cc: [email-masked], Myung-Ki Shin <[email-masked]>
Subject: WG Last Call: draft-ietf-v6ops-application-transition-01.txt

Hi all,

This is a WG Last Call for comments on sending
draft-ietf-v6ops-application-transition-01.txt, "Application Aspects
of IPv6 Transition", to the IESG for consideration as Informational:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-01.txt

Please review the document carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this document
is ready to go to the IESG.

The last call will end in about 3 weeks (due to the IETF), on 20th 
March.

Pekka & Jonne

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Mar 2004 15:17:17 +0200 (EET)

Hi,

Below are my presonal comments/final edits to the the WG last call of 
the application transition document.

semi-editorial/substantial
--------------------------

    necessary. However, these wrapper applications will actually
     probably have to do more than just perform a DNS lookup or figure  
     out the literal IP address given.  Thus, they may get complex, and

==> remove "probably" because this is a fact. :)

     There is an another consideration on IPv6 address literals in SMTP
     commands [RFC 2821], i.e., [IPv6: 2001:db8::1].

==> reword to better flesh this out, e.g.:

     One should note that some applications may also represent IPv6 address
     literals differently; for example, SMTP [RFC 2821] uses
     [IPv6:2001:db8::1].

...

     When selecting the destination address, applications usually ask a
     resolver for the destination IP address. The resolver returns a set
     of valid IP addresses from a hostname. Unless applications have a
     specific reason to select any particular destination address, they
     should just try each element in the list until the communication
     succeeds.

==> it seems that 5.4.1 does not mention the case of app selecting source
address at all.  Add a new paragraph like:

     In some cases, the application may need to specify its source
     address.  Then the destination address selection process picks the best
     destination for the source address (instead of picking the best source
     address for the chosen destination address).  Note that there may
     be an increase in complexity for IP-version independent applications
     which have to specify the source address (especially for client
     applications; fortunately, specifying the source address is not
     typically required), if it is not yet known which protocol will be used
     for communication.

...

     FIXME: Application framing has relations e.g. with Path MTU
     Discovery and application design which need to be analyzed better.

==> apparently in application layer framing, some considerations are still
TBD.  Flesh these out a bit, by replacing the paragraph with like:

     Note that the most optimal ALF depends on dynamic factors such
     as Path MTU or whether IPv4 or IPv6 is being used (due to different
     header sizes, possible IPv6-in-IPv4 tunneling overhead, etc.).
     These have to be taken into consideration when implementing
     application framing.

...

     When possible, applications should store names, such as FQDNs,
     instead of storing addresses.

==> make this more generic, e.g. by rewording to:

     When possible, applications should store names such as FQDNs,
     or other protocol-independent identities instead of storing
     addresses.

...

     Another problem is/has been that IPv6 multicast does not yet have a
     standardized mechanism for traditional Any Source Multicast for  
     Interdomain multicast.

==> this is no longer quite true (and wouldn't be a good way to state
this in an RFC in any case), so reword slightly:

     Another problem has been that IPv6 multicast in Interdomain using
     the traditional Any Source Multicast has not been possible.

...

     IPv4 and IPv6, but it is likely that PIM-SSM will become more   
     widely deployed in IPv6 due to its simpler architecture.

==> s/likely/possible/ -- it's difficult to predict the future! :)

     Both are from the basic socket extensions for IPv6. Since these
     functions are not protocol independent, we should write code for
     the different address families.

     A more detailed examples are described in appendix A.

     Note that inet_ntop()/inet_pton() lose the scope identifier (if
     used e.g. with link-local addresses) in the conversions, contrary
     to the getaddrinfo()/getnameinfo() functions.

==> As we want to achieve protocol-independence it's IMHO bad practice to
not be clear what's the recommendation.  I would:

 1) describe the first paragraph above better, and possibly also
 2) move the examples using getaddrinfo/getnameinfo from appendix A here.

Below is my suggestion for the text if we're doing that:
======
6.2.3 Binary/presentation format conversion

     In addition, we should consider the binary and presentation address
     format conversion APIs.  The following functions convert network
     address structure in its presentation address format and vice
     versa:

       inet_ntop()
       inet_pton()

     Both are from the basic socket extensions for IPv6. However, these
     conversion functions are protocol-dependent; instead it is better to
     use getnameinfo()/getaddrinfo() as follows (inet_pton and inet_ntop
     equivalents are described in Appendix A).

     Conversion from network address structure to presentation format
     can be written:

      struct sockaddr_storage ss;
      char addrStr[INET6_ADDRSTRLEN];
      char servStr[NI_MAXSERV];
      int error;

      /* fill ss structure */

      error = getnameinfo((struct sockaddr *)&ss, sizeof(ss),
                          addrStr, sizeof(addrStr),
                          servStr, sizeof(servStr),
                          NI_NUMERICHOST);

     Conversions from presentation format to network address structure
     can be written as follows:

      struct addrinfo hints, *res;
      char addrStr[INET6_ADDRSTRLEN];
      int error;

      /* fill addrStr buffer */

      memset(&hints, 0, sizeof(hints));
      hints.ai_family = AF_UNSPEC;

      error = getaddrinfo(addrStr, NULL, &hints, &res);
      if (error != 0) {
          /* handle getaddrinfo error */
      }

      /* res->ai_addr contains the network address structure */
      /* ... */
      freeaddrinfo(res);
--- -- -- - -- -

Appendix A. Other Binary/Presentation Format Conversions

     Section 6.2.3 described the preferred way of performing
     binary/presentation format conversions; these can also be
     done using inet_pton() and inet_ntop() by writing
     protocol-dependent code.  This is not recommended, but provided
     here for reference and comparison.

     Note that inet_ntop()/inet_pton() lose the scope identifier (if
     used e.g. with link-local addresses) in the conversions, contrary
     to the getaddrinfo()/getnameinfo() functions.

A.1 Binary to Presentation Using inet_ntop()

[[ text from A.1 up until "buffer length." ]]

A.2 Presentation to Binary Using inet_pton()

[[ similar ]]
======

     Note: in the following examples, the socket() return value error
     handling could be simplied by substituting special checking of
     specific error numbers by always continuing on with the socket
     loop.  Whether this is a better idea should be considered in more
     detail.

==> remote the "Whether" -sentence.

8. Security considerations

     A number of transition mechananisms define ways of constructing  
     IPv6 adddresses using IPv4 addresses. There are a number of kinds
     of IPv4 addresses that require careful treatment due to know
     security issues [TRANSEC].

==> this paragraph seems irrelevant to the application transition, so
remove (also the reference).  Instead, add something like:

     There are a number of security considerations with IPv6 transition
     but those are outside the scope of this memo.

     To ensure the availability and robustness of the service even when
     transitioning to IPv6, this memo described a number of ways to
     make applications more resistant to failures by cycling through 
     addresses until a working one is found.  Doing this properly is
     critical to avoid unavailability and loss of service.

...

     One particular point about application transition is how IPv4-
     mapped IPv6-addresses are handled.  The use in the API can be seen
     as both a merit (easier application transition) and as a burden
     (difficulty in ensuring whether the use was legimate) [V6MAPPED].
     This may have to be considered in more detail.

==> s/may have to/should/
==> s/detail/detail when designing applications/

9. Acknowledgements

==> I think it would be appropriate to acknowledge or refer to other work
which has been made before or after starting this process; for example,
[IP-GGF] and [AF-APP] are listed in references, but not referred in the
body.  Those could be good candidates for mentioning here.

editorial
---------

      Case 1 : IPv4-only applications in a dual-stack node.
               IPv6 protocol is introduced in a node, but
               applications are not yet ported to IPv6.

==> s/to IPv6/to support IPv6/

3. Problems with IPv6 application transition

==> in all of the section headings, use uppercasing except for certain small
words; like: Problems with IPv6 Application Transition

     if a server application does not support IPv6 yet, but runs on a   
     dual-stack machine for other IPv6 services, and this is listed with
     an AAAA record in the DNS, the client application will fail to

==> s/an AAAA/a AAAA/ (three different places)
==> s/this is/this host is/

     In consequence, the application should request all IP addresses
     without address family constraints and try all the records returned
     from the DNS, in some order, until a working address is found.  In
     particular, the application has to be able to handle all IP
     versions returned from the DNS.

==> here, one should add a reference to [DNSOPV6] which was already added to
the references; either immediately after this paragraph, or with a statement
like "This issue is discussed in more detail in [DNSOPV6]."

     When [BIA] or [BIS] is used, the problem described in section 3.2
     becomes an issue --the IPv4 client in a [BIS]/[BIA] node trying to 
     connect to an IPv4 server in a dual stack system-- arises.

==> remove "becomes an issue" or move it to replaces "arises" at the end.

     [BIS] or [BIA] does not work with all kinds of applications. In  

==> s/does/do/ ?

     As we have seen in the previous section, applications should be
     ported to IPv6. The easiest way to port an IPv4 application is to
     substitute the old IPv4 API references with the new IPv6 one-to-one
     API mapping.

==> s/one-to-one API mapping/APIs with one-to-one mapping/

     telnet6). This case is undesirable since maintaining two versions
     of the same source code per application, could be a difficult task.
     In addition, this approach would cause problems for the users when

==> remove "," before "could"

     Most implementations of dual stack allow IPv6-only applications to
     interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to
     IPv6 applications on a dual-stack node, reach their destination
     because their addresses are mapped to IPv6 ones using IPv4-mapped
     IPv6 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4
     address x.y.z.w.

==> remove "," before "reach"

 This
     option could be useful if applications use new IPv6 features, such
     as flowlabel.

==> s/flowlabel/Flow Label/

     The first method is not recommended because of a significant amount
     of problems associated with selecting the right applications.This
     scenario is described in sections 3.2 and 3.3.

==> s/This scenario is/  These problems are/

   regarding IPv4-mapped IPv6 addresses on the wire are legitimate but
     disabling it internally breaks one transition mechanism for server
     apps which were originally written to bind and listen to a single
     socket using a wildcard address. This forces the software developer

==> s/bind/bind()/
==> s/listen/listen()/
==> s/apps/applications/

     could be removed. Since we have only one version of each   
     application, the source code will be typically easy to maintain and
     to modify, and there are no problems managing which application to
     select for which purpose.

==> s/purpose/communication/

     Implementations typically by-default prefer IPv6 if the remote node   
     and application support it.  However, if IPv6 connections fail,   
     dual applications will automatically try IPv4 ones. The resolver
     returns a list of valid addresses for the remote node and
     applications can iterate through all, first trying IPv6 ones, until
     connection succeeds.

==> s/dual applications/version-independent applications/
==> s/, first trying IPv6 ones,/of them/ -- that was already stated.

     If the source code is written in a protocol-dependent way, the
     application will suport IPv4 and IPv6 explicitly using 2 separate

==> s/suport/support/

 Note that there are some differences in bind()
     implementation, whether you can first bind to the IPv6 wildcard
     address, and then the IPv4.

==> reword:

 Note that there are some differences in bind()
     implementation, whether you can first bind to the IPv6, and
     then IPv4, wildcard addresses.

...

     - Network information storage: IP address data structures.
        The new structures must contain 128-bit IP addresses. The use of
        generic address structures, which can store any address family,
        is recommended.
        Sometimes special addresses are hard-coded in the application
        source; developers should pay attention to them in order to use
        the new address format. Some of these special IP addresses are:
        wildcard local, loopback and broadcast. IPv6 does not have
        the broadcast addresses, so applications can use multicast
        instead.

==> add new paragraph before "Sometimes" ?

==> s/source/source code/.

      - Network configuration options.
        They are used when configuring different communication models
        for Input/Output (I/O) operations (blocking/nonblocking, I/O
        multiplexing, etc) and should be translated to the IPv6 ones.

==> s/etc/etc./

     Applications can use 1280 octets as a data length. [RFC 2460]
     specifies an IPv6 requirement that every link in the Internet have
     a Maximum Transmission Unit (MTU) of 1280 octets or greater.

==> reword to be more fluent:

     Applications can use 1280 octets as a data length: every IPv6
     link must have a Maximum Transmission Unit (MTU) of 1280 octets
     or greater [RFC 2460].

...

     - The same node can reach a destination host using different
        IP addresses.

==> expand this a bit by rewording:

     - The same node can reach a destination host using different
        IP addresses, possibly with a different protocol version.

...

     to peer systems with their own rendez-vous and discovery

==> remove "-".

     These can perform hostname/address and service name/port lookups,
     though the features can be turned off if desirable. getaddrinfo()
     can return multiple addresses, as below:

==> s/get/Get/

     As well, it is not preferred to hardcode AF-dependent knowledge
     into the program. The construct like below should be avoided:

==> s/As well, it/It/

       *  - no server at all, if getaddrinfo supports IPv6, but the
       *    system doesn't, and socket(AF_INET6, ...) exists with an
       *    error.

==> s/exists/exits/

       *  - an IPv4 connection to the IPv4 destination,
       *  - an IPv6 connection to an IPv6 destination,

==> s/the/an/

     In a client code, when multiple addresses are returned from
     getaddrinfo(), we should try all of them until connection succeds. 
     When a failure occurs with socket(), connect(), bind(), or some    
     other function, go on to try the next address.

==> s/succeds/succeeds/
==> s/go on/the code should go on/

 [2893BIS]   E. Nordmark, "Transition Mechanisms for IPv6 Hosts and
             Routers," <draft-ietf-v6ops-mech-v2-02.txt>, February 2003,
             Work-in-progress.

==> move this to Informative, because it's not required reading, and could
cause blockage as well.

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

---

From: Myung-Ki Shin <[email-masked]>
Date: Thu, 18 Mar 2004 16:22:31 +0900

Thanks, Pekka.

I agree on all of your edits and suggestions.

At this time, I'm preparing the revision (-02) of this draft.
After publication (-02), I think this document
will be ready to go to the IESG.

Thanks,
Myung-Ki.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Myung-Ki Shin |  [email-masked]
ETRI/PEC      |  161 Kajong-Dong, Yusong-Gu,
              |  Taejon, 305-350, Korea
              |  Tel:+82-42-860-4847
              |  Fax:+82-42-861-5404
              |  http://pec.etri.re.kr/~mkshin/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Mar 2004 09:14:09 +0100

> so.  Please provide feedback.  Thanks!

"A week or so" expires today or so :-) 

Most of my comments on the previous version have been addressed. I remain 
a little unhappy about one paragraph. Here's the previous interchange between 
me and Pekka:

> > > 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).
> > 
(BC)> > I'm not sure why it would be unscalable - messy, yes, but not unscalable.
(PS)> 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 :-).
> 
(BC)> > 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"?
> 
(PS)> 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.  

(back to today...)

I see Pekka's points but the phrase "that would be completely unscalable"
still worries me. Could we replace it, for example by
"that would be completely impractical" ?

Incidentally, this document is referenced by the GGF draft on
IPv6 guidelines for GGF protocol designers, which by strange coincidence
finishes WG Last Call over in the GGF today too. See
http://forge.gridforum.org/projects/ipv6-wg/document/draft-ggf-ipv6-ip-independent-guide-00/en/1

(Warning- some mailers may split this URL into two pieces.)

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Mar 2004 13:17:06 +0200 (EET)

> "that would be completely impractical" ?

That's fine with me.