Subject: RE: IPv6 Address Architecture update question

From: "Bound, Jim" <[email-masked]>
Date: Tue, 1 Feb 2005 23:25:50 -0500

I am not going to dive in here and increase my responses on this thread
and eat up my limited messages I will bombard this list with ok,
supporting the mail model less mail is better and keeping low on Rob's
messages list each week.  But, besides v4mapped being widely deployed on
"vendor" "production" shipping code bases, used today by applications, I
believe v4mapped is a very useful and elegant solution for application
providers to provide a common binary v4+v6 solution as an option
"technically" and superior to not using it.  I emphatically disagree
with Itojun, cmetz, et al referenced and we had this debate many years
ago, then again had the debate, and that view lost and we should not
revisit it again.  No one has to implement a port to IPv6 or a new
application with v4mapped addresses.  It is merely an option that is
available to a programmer and upto them and it is available on
production platforms today.  

Mark Andrews point is quite valid and that is the responsibility of each
implementation to document their use of v4mapped, and out of scope for
the IETF as that is an implementation manner.  Whether it is useful to
document various behaviors (INFO, BCP) is not clear to me that is
necesary and see UNIX Network Programming Volume I Third Edition. 

Regards,
/jim

> -----Original Message-----
> From: Radhakrishnan Suryanarayanan [mailto:[email-masked]] 
> Sent: Tuesday, February 01, 2005 11:10 PM
> To: Bound, Jim; Bob Hinden; IPv6 WG
> Subject: Re: IPv6 Address Architecture update question
> 
> I too agree with Jim's view. Leaving mapped addresses as it 
> is the best way to go about.
> changing APIs usage at this stage when they are already 
> deployed is quite difficult.
> 
> ----- Original Message -----
> From: "Bound, Jim" <[email-masked]>
> To: "Bob Hinden" <[email-masked]>; "IPv6 WG" <[email-masked]>
> Sent: Tuesday, February 01, 2005 10:52 PM
> Subject: RE: IPv6 Address Architecture update question
> 
> 
> Folks,
> 
> I strongly agree with Bob Hinden.  We have been down this path before
> and discussion.  IPv4-Mapped addresses are now used on every 
> production
> implementation and in most IPv6 production IP dual stacks.  
> They cannot
> be removed and the industry will not and does not support 
> such a change.
> The APIs are in use now also by Application Providers porting to IPv6.
> There is absolutely no reason to deprecate Mapped-Addresses 
> and such an
> idea is totally unacceptable for all the reasons below and also we
> should not alter our base specification.
> 
> Regarding compatible addresses they are harmless but not being used by
> most implementations or deployments, 6to4 is used.   But I 
> see not point
> in deprecating that either.
> 
> Regards,
> /jim
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Bob Hinden
> > Sent: Tuesday, February 01, 2005 7:27 AM
> > To: IPv6 WG
> > Subject: Re: IPv6 Address Architecture update question
> >
> > Hi,
> >
> > In response to my question about keeping the "IPv6 Addresses
> > with Embedded
> > IPv4 Addresses" (e.g., compatible and mapped) I heard the following:
> >
> > "I think that at least all the BSD's and most Linuxes are 
> using this.
> > They allow binding on :: (IPv6 any) and also accept IPv4
> > connections on the same socket, which are then represented in
> > netstat etc as ::ffff:1.2.3.4.", "IMO the section can be
> > removed and programmers need to be learned the correct thing
> > for which I always very inclined to point people to Eva's
> > excellent document at
> > http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html and/or
> > draft-ietf-v6ops-application-transition-02.txt"
> >
> > "They should not be removed. Implementations already support
> > it, removing would just create confusion. I don't see any
> > harm in keeping it in."
> >
> > "helps with porting applications" and "dropping this section
> > will create confusion and chaos for the already ported applications"
> >
> > "Among other things, this would break the just published full
> > Standard for URIs (RFC 3986).", "I suspect some people have used the
> > ::10.1.2.3 format to carry IPv4 addresses in an IPv6
> > container, simply for convenience. I think this is very
> > convenient and should be available.", " otoh the
> > ::FFFF:10.1.2.3 format seems useless to me."
> >
> > "IPv4-mapped addresses facilitate an important
> > interoperability mechanism in the socket API (RFC 3493,
> > section 3.7).", "the API still needs a way to represent IPv4
> > addresses in a way that preserves compatibility between IPv6
> > and IPv4 hosts.  Removal just makes transition all the more
> > time-consuming and difficult for software developers.
> >
> > "rather see clarification of the use of embedded addresses in
> > the document rather than complete removal.  Ie. add a
> > statement to the effect of 'Embedded addresses are intended
> > for internal representation only'."
> >
> > "It is clear that the mapped addresses are widely used and
> > useful, and a lot of people have raised their concerns about
> > removing that.", "I suggest just simply removing compatibles."
> >
> > "Removal and formal deprecation would simplify life for
> > software developers.", "We might as well rid developers of
> > the burden of having to cope with mapped-address sockets as
> > well.", "Anyway, in summary, removal would in my opinion
> > actually make transition much easier for software developers,
> > not harder. Don't let the superficial ease of the
> > mapped-address API fool you :)"
> >
> > My take of this is that they should remain in the IPv6
> > address architecture.  There is current usage and removing
> > them would break other specifications.
> >
> > Thanks,
> > Bob
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> 
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 02 Feb 2005 09:04:56 +0100

On Tue, 2005-02-01 at 23:25 -0500, Bound, Jim wrote:
> messages list each week.

Better waste less bandwidth with the above and send a bit more
messages ;)

>   But, besides v4mapped being widely deployed on
> "vendor" "production" shipping code bases, used today by applications,

Please name these 'vendor's and 'applications' I am quite sure if you
ask them that they think it should be removed if they have made to try
the code run on more than a single platform.

> "technically" and superior to not using it.

Please look at the Apache2 APR code which demonstrates how 'elegant'
this solution is because it is not default.

>   I emphatically disagree
> revisit it again.

You mean some people shoved the arguments away without having any
background in the subject?

> No one has to implement a port to IPv6 or a new

The production platforms mostly use KAME stacks, the other is Windows.
Guess what both of these platform don't have, at least turned on per
default: ipv4-mapped.

Please name the platforms you call 'production'.

> necesary and see UNIX Network Programming Volume I Third Edition. 

Which nicely mentions the use of getaddrinfo() and separately doing ::
and 0.0.0.0 with IPV6_ONLY sockets because of the inherit issues
mentioned by Itojun.

Greets,
 Jeroen

---

From: Francis Dupont <[email-masked]>
Date: Wed, 02 Feb 2005 17:24:13 +0100

I agree with you (Jim): the question is philosophical: "is IPv6 a new
version of the IP protocol or is IPv6 a new protocol?". In the first
case it is natural to inject the IPv4 space into the IPv6 space and
ignore the version when it is irrelevant, i.e., in 99% of real cases.

Of course I am for this but the issue is there are implementations
with really separated IPv4 and IPv6 stacks so for these implementations
the "one socket for a server" coding style does not work. As the "two
sockets" coding style can get some trouble with some other implementations
the IPV6_V6ONLY stuff was invented in order to make possible one day
a coding style guaranteed to work everywhere.

So IMHO the only useful answer we can get from this discussion is about
this day, i.e., are there used implementations today which don't support
the "two sockets for a server with IPV6_V6ONLY set when it exists"
(i.e., #@$* but universal) coding style?

Thanks

[email-masked]