Re: Developing IP version-independent Applications

[js.jason.lin@foxconn.com]

Hi Pekka,

I think it's good to add your suggestion.
It directly addresses the major reason why we should consider the
"IPv4-only" node.
Thank you.

Regards,
Jason.



                                                                                                                               
                      Pekka Savola                                                                                             
                      <pekkas@netcore.f        To:       js.jason.lin@foxconn.com                                              
                      i>                       cc:       v6ops@ops.ietf.org                                                    
                                               Subject:  Re: Developing IP version-independent Applications                    
                      2004/05/25 02:54                                                                                         
                      PM                                                                                                       
                                                                                                                               
                                                                                                                               




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?

On Fri, 21 May 2004, Pekka Savola wrote:
> (I waited for other comments, but they didn't appear :)
> On Mon, 17 May 2004 js.jason.lin@foxconn.com wrote:
> > On Sat, 15 May 2004 js.jason.lin@foxconn.com wrote:
> > 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.
> >       <>
>
> 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?
>
> > 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.
> >       <>
>
> Totally agree here, and this was the most important original reason
> for adding this ipv4-only section.
>
> > 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.
>
> Yes, that's probably the most important case.
>
> >       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?
> >       <>
>
> 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.
>
>

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