Re: [Int-area] practical issues with using v4-mapped addresses for nat64
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Int-area] practical issues with using v4-mapped addresses for nat64

On 24 jul 2008, at 7:27, Pekka Savola wrote:
What we need is for IPv6-only systems to successfully send and receive IPv6 packets with mapped addresses as the source or destination. And we haven't seen any type of system do this so far.
I'm not sure that "we" (if it implies the IETF and network community in general) need to be able to send and receive v6 packets with mapped addresses as the source or destination. 

The premise being that we'd use the v4mapped prefix for NAT64.
Why is using the mapped addresses on the wire such a holy grail of v6-only operation? 

See my list of advantages the other day.
The most compelling is that applications that think they're using IPv4 will work. With existing NAT-PT or the NAT64 draft as it is now this isn't the case.
I.e., when I was at the LACNIC meeting IPv4 was turned off, but unlike at the last IETF meeting, there was a NAT-PT translator present. So I could browse the web, connect to Jabber, send/receive email etc even though the seFrom int-area-bounces at ietf.org Thu Jul 24 01:32:40 2008 
Return-Path: <int-area-bounces at ietf.org>
X-Original-To: int-area-archive at megatron.ietf.org
Delivered-To: ietfarch-int-area-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3BFD43A67CF;
	Thu, 24 Jul 2008 01:32:40 -0700 (PDT)
X-Original-To: int-area at core3.amsl.com
Delivered-To: int-area at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 525053A67CF
	for <int-area at core3.amsl.com>; Thu, 24 Jul 2008 01:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.15
X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, NO_RELAYS=-0.001] 
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id lBy2Wru1VDCl for <int-area at core3.amsl.com>;
	Thu, 24 Jul 2008 01:32:37 -0700 (PDT)
Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2])
	by core3.amsl.com (Postfix) with ESMTP id 0EF2F3A67A4
	for <int-area at ietf.org>; Thu, 24 Jul 2008 01:32:36 -0700 (PDT)
Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]
	([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6O8X3K5055575
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 24 Jul 2008 10:33:04 +0200 (CEST)
	(envelope-from iljitsch at muada.com)
Message-Id: <02018E7E-07E4-40F7-9A16-F53C43E6813C at muada.com>
From: Iljitsch van Beijnum <iljitsch at muada.com>
To: Pekka Savola <pekkas at netcore.fi>
In-Reply-To: <alpine.LRH.1.10.0807240820540.23361 at netcore.fi>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Thu, 24 Jul 2008 10:33:16 +0200
References: <48846C5B.2050602 at it.uc3m.es>
	<E9CACA3D8417CE409FE3669AAE1E5A4F04589BDD87 at NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
	<F7F81ECB-FDBF-401A-82D9-FEB27E638C41 at muada.com>
	<alpine.LRH.1.10.0807240820540.23361 at netcore.fi>
X-Mailer: Apple Mail (2.926)
Cc: Philip Matthews <philip_matthews at magma.ca>,
	"int-area at ietf.org" <int-area at ietf.org>,
	Brian E Carpenter <brian.e.carpenter at gmail.com>
Subject: Re: [Int-area] practical issues with using v4-mapped addresses for
	nat64
X-BeenThere: int-area at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>,
	<mailto:int-area-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area at ietf.org>
List-Help: <mailto:int-area-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>,
	<mailto:int-area-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: int-area-bounces at ietf.org
Errors-To: int-area-bounces at ietf.org

On 24 jul 2008, at 7:27, Pekka Savola wrote:
What we need is for IPv6-only systems to successfully send and receive IPv6 packets with mapped addresses as the source or destination. And we haven't seen any type of system do this so far.
I'm not sure that "we" (if it implies the IETF and network community in general) need to be able to send and receive v6 packets with mapped addresses as the source or destination. 

The premise being that we'd use the v4mapped prefix for NAT64.
Why is using the mapped addresses on the wire such a holy grail of v6-only operation? 

See my list of advantages the other day.
The most compelling is that applications that think they're using IPv4 will work. With existing NAT-PT or the NAT64 draft as it is now this isn't the case.
I.e., when I was at the LACNIC meeting IPv4 was turned off, but unlike at the last IETF meeting, there was a NAT-PT translator present. So I could browse the web, connect to Jabber, send/receive email etc even though the servers dirvers didn't have IPv6 addresses.
However, a SIP client, Skype and BitTorrent didn't work: they explicitly use IPv4 addresses, which weren't reachable. Obviously those clients can be upgraded, but it would be extremely useful if existing IPv4 applications could work through a NAT64 translator.
On the other hand, this can also be accomplished with an arbitrary prefix if the host knows the prefix and intercepts API calls that would normally generate IPv4 packets but turn those into IPv6 packets towards the translator if there is no IPv4 connectivity.
As a destination address, it might result in IPv6 DFZ being polluted with the corresponding v4 routes except if you only use it in very restricted environments (e.g. default route only). 

Yes, and if the sky fell we'd all be covered in blue.
As far as I know, this hasn't happened with the 6to4 prefix so I see no reason to reject using a well known prefix to avoid this risk.
As a source address, if the node(s) on link are also provided with real IPv6 addresses, this would be indistinguishable from source address spoofing.
Only translators would transmit packets with v4mapped source addresses, so this isn't much of an issue.
I'd like folks to just forget about the mapped addresses on the wire and find other kind of solutions for this problem. 

Please provide better reasons.
_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area


dn't have IPv6 addresses.
However, a SIP client, Skype and BitTorrent didn't work: they explicitly use IPv4 addresses, which weren't reachable. Obviously those clients can be upgraded, but it would be extremely useful if existing IPv4 applications could work through a NAT64 translator.
On the other hand, this can also be accomplished with an arbitrary prefix if the host knows the prefix and intercepts API calls that would normally generate IPv4 packets but turn those into IPv6 packets towards the translator if there is no IPv4 connectivity.
As a destination address, it might result in IPv6 DFZ being polluted with the corresponding v4 routes except if you only use it in very restricted environments (e.g. default route only). 

Yes, and if the sky fell we'd all be covered in blue.
As far as I know, this hasn't happened with the 6to4 prefix so I see no reason to reject using a well known prefix to avoid this risk.
As a source address, if the node(s) on link are also provided with real IPv6 addresses, this would be indistinguishable from source address spoofing.
Only translators would transmit packets with v4mapped source addresses, so this isn't much of an issue.
I'd like folks to just forget about the mapped addresses on the wire and find other kind of solutions for this problem. 

Please provide better reasons.
_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.