Re: IPv6 Address Architecture update question

Bob Hinden <bob.hinden@nokia.com> Tue, 01 February 2005 12:55 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26277 for <ipv6-web-archive@ietf.org>; Tue, 1 Feb 2005 07:55:00 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvxqm-0000kA-Hs for ipv6-web-archive@ietf.org; Tue, 01 Feb 2005 08:13:48 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvxR8-0002aV-2l; Tue, 01 Feb 2005 07:47:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvxKl-0001eH-7P for ipv6@megatron.ietf.org; Tue, 01 Feb 2005 07:40:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25061 for <ipv6@ietf.org>; Tue, 1 Feb 2005 07:40:41 -0500 (EST)
Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvxcu-0000EG-Qq for ipv6@ietf.org; Tue, 01 Feb 2005 07:59:29 -0500
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j11CeSO03866 for <ipv6@ietf.org>; Tue, 1 Feb 2005 14:40:38 +0200 (EET)
X-Scanned: Tue, 1 Feb 2005 14:27:21 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE
Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j11CRLTw017364 for <ipv6@ietf.org>; Tue, 1 Feb 2005 14:27:21 +0200
Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00enB8VP; Tue, 01 Feb 2005 14:27:18 EET
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j11CRDx10151 for <ipv6@ietf.org>; Tue, 1 Feb 2005 14:27:13 +0200 (EET)
Received: from l5131412.nokia.com ([172.21.39.184]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Feb 2005 14:27:13 +0200
Message-Id: <6.1.2.0.2.20050201032232.02f44e90@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Tue, 01 Feb 2005 04:27:11 -0800
To: IPv6 WG <ipv6@ietf.org>
From: Bob Hinden <bob.hinden@nokia.com>
In-Reply-To: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com>
References: <6.1.2.0.2.20050131043340.02fbf0c0@mailhost.iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-OriginalArrivalTime: 01 Feb 2005 12:27:13.0340 (UTC) FILETIME=[5BB187C0:01C50859]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Subject: Re: IPv6 Address Architecture update question
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15

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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------