RE: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt

["Bound, Jim" <jim.bound@hp.com>]

We cannot deprecate usage of IPv4 Mapped Addresses for the API (not
speaking of the wire) they are deployed and part of RFC 3493 and IEEE
standard, and the API is widely deployed on all product platforms that
require APIs.  There are many uses for IPv4 Mapped Addresses and this
has been documented in the Netscape Mozilla code base and now in many
code bases.  An application may want to treat all addresses as IPv6
including IPv4 and how to do this is documented in RFC 3493.  The
product and most research implementors will not deprecate IPv4 Mapped
addresses because they have an important use in the industry and for
specific customers and research.  This has all been discussed before and
in the spirit of not raising this to insanity mail list responses I will
not respond further on this topic this week or maybe even next week
unless I hear something new and I did not.  Unless the Chairs
specifically ask me to respond.

Please do try to limit your messages on this mail list to 10-15 per
week.  Thank You.

/jim

> -----Original Message-----
> From: Mauro Tortonesi [mailto:mtortonesi@ing.unife.it] 
> Sent: Friday, September 12, 2003 8:12 AM
> To: Iljitsch van Beijnum
> Cc: v6ops@ops.ietf.org
> Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt 
> and draft-itojun-v6ops-v4mapped-harmful-01.txt 
> 
> 
> On Fri, 12 Sep 2003, Iljitsch van Beijnum wrote:
> 
> > On vrijdag, sep 12, 2003, at 11:33 Europe/Amsterdam, Mauro Tortonesi
> > wrote:
> >
> > > then my credo as a developer is "ipv6 is a brand new protocol", 
> > > because AF_INET6 sockets have many options that are not 
> applicable 
> > > to ipv4 connections, and writing applications that make 
> use of the 
> > > ipv4-mapped catch-all approach will be a great problem for 
> > > developers (that will find themselves writing __a lot__ of 
> > > checks/workarounds for special cases and
> > > will become crazy during the testing/debugging process).
> >
> > So what's the alternative? Ripping mapped addresses out of current 
> > implementations doesn't make sense for many reasons.
> 
> sure, but we could deprecate usage of ipv4-mapped addresses.
> 
> 
> > The only question is whether you should/want to use them. 
> If you want 
> > to do stuff with IPv6 that you can't do with IPv4, you'll 
> have to do a 
> > lot of checking regardless of how you do it.
> 
> yes, but they're always less than the checks you would do if 
> you were also supporting ipv4-mapped addresses.
> 
> 
> > If you feel using the IPv6 socket API for IPv6 and the IPv4 
> socket API 
> > for IPv4 makes more sense, then by all means, do it that 
> way. But for 
> > simple applications I think it's a huge plus to be able to 
> talk to the 
> > network in a unified way without having to spend time and effort on 
> > making the IPv4/IPv6 distinction. Obviously this means you can't do 
> > any IPv6-specific stuff.
> 
> this could be a plus only for for very simple apps where the 
> developers don't care for portability or robustness.
> 
> 
> > > moreover, i think that the ipv4-mapped catch-all approach in the 
> > > development of ipv6-enabled apps may eventually become an 
> obstacle 
> > > for widespread adoption of production quality 
> ipv6-enabled software 
> > > (since it makes more difficult the use of the advanced ipv6 
> > > capabilities)
> >
> > I don't agree. Just tell the stack you don't want to talk IPv4.
> 
> not all the stacks support IPv6_V6ONLY, yet.
> 
> 
> > Also, in the document I read it seems half or more of the trouble 
> > comes from mixing IPv4 and IPv6 calls. So don't do that.
> 
> actually, this is not true. in fact, half or more of the 
> trouble comes from the fact that nearly every stack has a 
> different bind(2) behaviour.
> 
> 
> -- 
> Aequam memento rebus in arduis servare mentem...
> 
> Mauro Tortonesi                 mtortonesi@ing.unife.it
>                                 mauro@deepspace6.net
>                                 mauro@ferrara.linux.it
> Deep Space 6 - IPv6 with Linux  http://www.deepspace6.net
> Ferrara Linux User Group        http://www.ferrara.linux.it
> 
> 
>