Re: IPv6 Address Architecture update question

[Mark Andrews <[e-mail]>]

> 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

	I agree w/ Jim that they should not be removed.  What should
	be done is to identify where the different implementations
	behave differently and document the correct behaviour.

	e.g.
	    Can in6_pktinfo be used on mapped addresses?

	    Does :: trump a IPv4 socket bound to a interface address
	    when the same port is used?

	    Does :: trump a IPv4 socket bound 0.0.0.0 when the same port
	    is used?

	It is inconsistancies like this make using mapped addresses
	hard.

	The choice of whether to use mapped addresses should remain w/
	the appliacation developer.

	Mark
 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 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
> > [e-mail]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]

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