Subject: Re: Developing IP version-independent Applications

From: [email-masked]
Date: Mon, 17 May 2004 21:44:28 +0800

Hi Pekka,

Thanks for your information. Please refer to my opinion as follows.

Regards,
Jason.

                      Pekka Savola                                                                                             
                      <[email-masked]        To:       [email-masked]                                              
                      i>                       cc:       [email-masked]                                                    
                                               Subject:  Re: Developing IP version-independent Applications                    
                      2004/05/15 12:27                                                                                         
                      PM                                                                                                       

Hi,

Thanks for the comment!

On Sat, 15 May 2004 [email-masked] wrote:
> However, in an IPv4-only node, it's most likely that RFC 3493,
> "Basic Socket Interface Extensions for IPv6", is not supported on
> the platform. Applications written as "version-independent"
> convention could have a problem. For example, "getaddrinfo" or
> "getnameinfo" might not be supported on the node. I wonder if we
> still need conditional compilation for applications to separate the
> code for "dual-stack" and "ipv4-only" node respectively.

This may sound like a contradiction, but I don't think it is one in
practice.  I mean, getaddrinfo/getnameinfo are generic functions which
are supported by many vendors even before they appropriately support
IPv6, and the functions work even if IPv6 is disabled.  It is also
possible for the applications to include a version of
getaddrinfo/getnameinfo for those systems which do not support it or
the support is broken (actually, many apps already do that).

This allows eliminating the compile-time special casing from the code,
making the code simpler.

      <jason>
      I am not sure whether most IPv4-only really support such getaddrinfo
or getnameinfo
      API. But I am afraid to add a version of getaddrinfo/getnameinfo into
applications can be much
      complicated than using conditional compilation.
      <>

Further, the IPv4-only operation is most important in practice for
nodes which already would be able to support IPv6, but the support is
turned off.  The applications should continue to work under those
circumstances.

      <jason>
      I think this is really a good reason for "version-independent"
programming.
      In embedded system, whether to activate IPv6 or not is usually
determined in compilation time.
      However, for PC, IPv6 really can be changed dynamically.
      <>

Maybe the justification for this should be clarified a bit?  Would you
have ideas how to do that?

      <jason>
      IMHO, the key value of "version-independent" API is for the
situations where IPv6 can
      be DYNAMICALLY disabled. And before we claim the application written
in "version-independent" API
      can run in IPv4-only platform, we'd better make sure these
"version-independent" API is supported in
      those legacy IPv4-only platform in advance.

      Finally, I have one more related question:
      If my platform supported IPv4-mapped IPv6 address and the IPv6 won't
be disabled forever.
      Then for TCP server application, do you think it is enough to create
one IPv6 socket to
      server IPv4 and IPv6 TCP client? Or we still need to create two
sockets, one for each version,
      like the sample code described in Sec 6.3.1?
      <>

--
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: Pekka Savola <[email-masked]>
Date: Fri, 21 May 2004 21:32:47 +0300 (EEST)

inline..

(I waited for other comments, but they didn't appear :)

>       complicated than using conditional compilation.

Depends a lot on how the code is designed.  If you create your own
network connectivity manipulation functions, it should be quite easy
to make them conditional.  If you don't, you'll have to sprinkle
conditional conditions all over your code.  And that's a pain to 
maintain as well.

There's no winner or loser here.  I'm familiar with some open-source 
projects; most use only getaddrinfo and provide background 
compatibility code as appropriate.  Some others provide conditionally 
either at compile time.

It's a judgement call for the developer, and I'm not sure whether this 
needs text in this document.  It might be good to spell it out.  Do 
you have text suggestions?
 
>       However, for PC, IPv6 really can be changed dynamically.

Totally agree here, and this was the most important original reason 
for adding this ipv4-only section.
 
>       those legacy IPv4-only platform in advance.

Yes, that's probably the most important case.

>       like the sample code described in Sec 6.3.1?

The document takes no firm stance here, on purpose.  You have to make 
that decision based on the tradeoffs such as portability (some systems 
don't support mapped addresses), how you tread the addresses (e.g., 
whether you want to parse mapped addresses or v4 addresses), etc.

As for my personal opinion, I'd go for two sockets for long-term
projects, and possibly for one socket in some limited short-term
hacks.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 May 2004 09:54:34 +0300 (EEST)

Hi,

Unless I hear otherwise shortly, I'm suggesting we address your 
comments by adding a new paragraph after the 1st in section 4.4:

  The most important case is the application support on
  systems where IPv6 support can be dynamically enabled or disabled
  by the users.  Applications on such a system should be able to able to
  handle the situation where IPv6 would not be enabled.  The secondary
  scenario is when an application could be deployed on older systems
  which do not support IPv6 at all (even the basic getaddrinfo
  etc. APIs).  In that case the application designer has to make a
  case-by-case judgement call whether it makes sense to have compile-time
  toggle between an older and newer API (having to support both in the
  code), or whether to provide getaddrinfo etc. function support on
  older platforms as part of the application libraries.

.. would this satisfy your concerns, Jason?

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 26 May 2004 07:33:56 +0900 (JST)

> .. would this satisfy your concerns, Jason?

	it looks ok to me, and reflects current practice.

itojun