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

[Pekka Savola <pekkas at netcore.fi>]

On Fri, 25 Jul 2008, Iljitsch van Beijnum wrote:
> > Otherwise they end up transiting enterprise and backbone networks and 
> > potentially arriving at the destination which does something unexpected
>
> No, if there's no translator the packets won't end up at the destination 
> because the mapped prefix isn't routed on the v6 internet.

If it's the destination address -- yes, but you might be surprised how 
widely default routes are being used.  Enterprise-ISP egress use them 
a lot.  Even smaller ISPs use them a lot.  With the number of routes 
climing, one resolution is using a default route (+well selected more 
specifics) -- it might even end up used in medium size ISPs.  The 
result is probably that packets end up looping between two routers at 
some ISP's backbone until the hop count rearches zero.

If it's the source address (it wasn't obvious whether this would be 
used, but apparently at least in tFrom int-area-bounces at ietf.org  Fri Jul 25 22:10:57 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 5B7FA3A6923;
	Fri, 25 Jul 2008 22:10:57 -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 5FA683A685D
	for <int-area at core3.amsl.com>; Fri, 25 Jul 2008 22:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 
	BAYES_00=-2.599]
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 yzrMYTssdi3p for <int-area at core3.amsl.com>;
	Fri, 25 Jul 2008 22:10:55 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1])
	by core3.amsl.com (Postfix) with ESMTP id 2F2133A6923
	for <int-area at ietf.org>; Fri, 25 Jul 2008 22:10:54 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1])
	by netcore.fi (8.13.8/8.13.8) with ESMTP id m6Q5Ao3X020548;
	Sat, 26 Jul 2008 08:10:51 +0300
Received: from localhost (pekkas at localhost)
	by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6Q5Anr9020545;
	Sat, 26 Jul 2008 08:10:49 +0300
Date: Sat, 26 Jul 2008 08:10:49 +0300 (EEST)
From: Pekka Savola <pekkas at netcore.fi>
To: Iljitsch van Beijnum <iljitsch at muada.com>
In-Reply-To: <98800DEA-7B40-4731-A680-C95E32456D32 at muada.com>
Message-ID: <alpine.LRH.1.10.0807260805190.20409 at netcore.fi>
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>
	<02018E7E-07E4-40F7-9A16-F53C43E6813C at muada.com>
	<alpine.LRH.1.10.0807250808510.21379 at netcore.fi>
	<98800DEA-7B40-4731-A680-C95E32456D32 at muada.com>
User-Agent: Alpine 1.10 (LRH 962 2008-03-14)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV 0.93.1/7828/Fri Jul 25 23:48:11 2008 on otso.netcore.fi
X-Virus-Status: Clean
Cc: Philip Matthews <philip_matthews at magma.ca>,
	"int-area at ietf.org" <int-area at ietf.org>
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"
Sender: int-area-bounces at ietf.org
Errors-To: int-area-bounces at ietf.org

On Fri, 25 Jul 2008, Iljitsch van Beijnum wrote:
> > Otherwise they end up transiting enterprise and backbone networks and 
> > potentially arriving at the destination which does something unexpected
>
> No, if there's no translator the packets won't end up at the destination 
> because the mapped prefix isn't routed on the v6 internet.

If it's the destination address -- yes, but you might be surprised how 
widely default routes are being used.  Enterprise-ISP egress use them 
a lot.  Even smaller ISPs use them a lot.  With the number of routes 
climing, one resolution is using a default route (+well selected more 
specifics) -- it might even end up used in medium size ISPs.  The 
result is probably that packets end up looping between two routers at 
some ISP's backbone until the hop count rearches zero.

If it's the source address (it wasn't obvious whether this would be 
used, but apparently at least in translator->v6host direction), there 
is no check from this POV.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area


ranslator->v6host direction), there 
is no check from this POV.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area