Subject: (ngtrans) application transition draft comments

From: Pekka Savola <[email-masked]>
Date: Sun, 17 Mar 2002 15:27:59 +0200 (EET)

A few comments (in addition to those already sent for -00) on the
application transition draft, mostly just editorial at this stage..

--8<--

Abstract

     The document specifies application aspects of IPv6 transition. As
     IPv6 is deployed, there are some problems that the application
     developers and the administrators face.  This draft clarifies the
     problems occurred in transition periods between IPv4 applications
     and IPv6 applications. It also propose guidelines to implement and
     choose the suitable application under the various transition
     environments.  This document does not try to define any new
     protocol.  The proposals contained in this document are based on
     the work of the Ngtrans working group.

==> s/any new protocol/any new protocols/ [???]

     For short-term solutions [BIS] and [BIA] have been proposed, but
     these mechanisms SHOULD be used when an application-specific source
     code is not available. 

==> Incorrect; better say like "SHOULD NOT be used when
application-specific source code is available".  The emphasis is 
different.

     The document does not try to define any new protocol. The proposals
     contained in this document are based on the work of the Ngtrans
     working group.

==> any new protocols.

      Case 2 : An IPv4 application and an IPv6 native application
               over dual stack.
               An application is ported for IPv6 native. Therefore,

==> "An application is ported for IPv6 native" ==> "An application
is IPv6-only" ?

               there are two same applications with different protocol
               versions (e.g., ping and ping6).

==> the reason there are two versions in this case is because
ping and ping6 are so different it makes little sense in integrating them.

               An application is ported for both IPv4 and IPv6 support.

==> this sounds funny.

3.2 DNS name resolution

     The role of the DNS name resolver in a node is to get the list of
     destination addresses.  Recently, the DNS query and response
     traffic are sent by using IPv4, even though IPv6 addresses are
     being resolved, or by using IPv6 native. This issue have been
     already discussed in [DNS]. The issue of DNS name resolving related

==> sent by using IPv4 transport
==> s/IPv6 native/IPv6/ or IPv6 natively
==> "This issue has been", or "These issues have been"
==> "has already been", not "has been already"

     example, 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 a AAAA record in the DNS server, a client application
     will fail to connect to the server application, because there is a
     mis-match between the DNS query result (i.e., IPv6 addresses) and a
     server application version(i.e., IPv4).

==> this is an operational error in DNS configuration IMO.

     support application).  Therefore, the users are confused by their
     various application versions.  because they don't know the version

==> s/versions./versions,/

     of peer application by DNS query results. If there is a both IPv4
     and IPv6 support applications only on the system, there will be no

==> there are both IPv4 and IPv6 applications

4.1 An IPv4 application over dual stack

     The IPv6 protocol is already introduced in a node, but an
     application for it is not ported yet. It means an application is
     not yet available on IPv6 or the application for which source code
     is not available or lost.

==> s/for it is not ported yet/doesn't support IPv6 yet/
==> s/is not available or lost/is lost or not available/

     The main difference between [BIS] and [BIA] is that while [BIS] is
     for systems with no IPv6 stack, BIA is for systems with an IPv6
     stack. 

==> s/while [BIS]/[BIS]/ , /, BIA is for systems with an IPv6 stack//

However, [BIA] SHOULD be used only when an application
     source code is not available to prevent the mis-use of [BIA], for
     example, an excuse not to port software.

==> this has already been mentioned, same issue with SHOULD/SHOULD NOT
as above.

     In addition, [BIA] SHOULD not affect possible other IPv4
     connections.

==> I have no idea what this means?

     A client application running [BIA] may has the issue mentioned in
     section 3.1 and 3.2.  That is, a client node running BIA trying to
     contact a dual stack node on a port number that is only associated
     to an IPv4 application will fail.

==> s/[BIA] may/[BIA]/, perhaps also s/has the issue/have the issues/

     In order to solver the problem, there are 2 approaches. It may very
     well be application dependent.

==> s/solver/solve/

      1 - the client node should cycle through all the addresses and
          end up trying the IPv4 one.
          getaddrinfo() returns a list of addresses (tokens) to the
          application that cycles through the list.

==> This is a more generic problem, not limited to just this case.

4.2 Mixed an IPv4 application and an IPv6 application

==> the title makes very little sense

     As an application is ported for IPv6 native, ...

==> for IPv6 nateive is bad English.

     Native IPv6 application programs can be converted easily from the
     existing same IPv4 applications by means of one to one API mapping.
     For examples, native IPv6 applications will be implemented using
     gethostbyname2(), getipnodebyname(), or getaddrinfo(), instead of
     gethostbyname() for IPv4.  Theoretically, there will be no change
     of the number of code line.

==> s/of the number of code line/in the number of code lines/

==> not so trivial for server applications.

4.3 An application supporting both IPv4 and IPv6

     As an application is ported for both IPv4 and IPv6 support, the
     existing IPv4 application is removed.

==> s/IPv4/IPv4-only/

Appendix

     Implementing an application supporting both IPv4 and IPv6 ([Y2K-
     SOFT],[PORT-NET] and [AF-APP]).

      Rule 1 - Modifying codes to support both IPv4 and IPv6.
               so called, AF-independent code.

      1. Avoid IPv4 native or IPv6 native structures and APIs.

==> s/ native/-only/

==> In general, it's much better to talk about IPvX-only than native
applications..

      2. Instead, use structures and APIs supporting both
         IPv4 and IPv6.

       o struct sockaddr_storage
          struc sockaddr_storage {
            u_char ss_len;
            u_char ss_family;
            u_char padding[128-2];
         }

==> note: some implementations which don't implement RFC2553bis yet 
have no e.g. ss_len.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords