Re: [Int-area] discussion of the ISP shared address idea

[Brian E Carpenter <brian.e.carpenter at gmail.com>]

On 2008-08-01 04:00, Alan DeKok wrote:
> Brian E Carpenter wrote:
>> I don't understand why a customer using Net 10 can't be NATted (at the CPE)
>> into an ISP using Net 10. Since NATs completely separate two address
>> realms, I can't see any reason this would work any differently than
>> by inventing Net10bis.
> 
>   The same thing happens when companies buy oFrom int-area-bounces at ietf.org  Sat Aug  2 17:40:43 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 816F628C0FB;
	Sat,  2 Aug 2008 17:40:43 -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 8AFE628C0FB
	for <int-area at core3.amsl.com>; Sat,  2 Aug 2008 17:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[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 Z0mWAk6a1JLW for <int-area at core3.amsl.com>;
	Sat,  2 Aug 2008 17:40:40 -0700 (PDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176])
	by core3.amsl.com (Postfix) with ESMTP id 7201F28C0F8
	for <int-area at ietf.org>; Sat,  2 Aug 2008 17:40:40 -0700 (PDT)
Received: by wa-out-1112.google.com with SMTP id k34so1299480wah.25
	for <int-area at ietf.org>; Sat, 02 Aug 2008 17:41:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from
	:organization:user-agent:mime-version:to:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=mUpoD8dtByZlm7B/tO6ouxJJS/TWFpykzPUljKnD4eI=;
	b=sPMnqtfY4X2xehZVE+X9G2QQ9XL9jrPNQ+il+/3k5V/cut+NGI3x5XK1h02bEXVxwK
	EMIyEqAZfL/bLCNuSZbKeLCAkKvpSWTuMqpaWf5QcNzmVnNsnic6o4nU/o4sEsd11PWP
	grezFJgIMgq0Nu8jDBBFtofDRhNZwlt3mgfdI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:organization:user-agent:mime-version:to:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	b=OgniwSGVagmOX8FbzLpS1XnMPC1OyXf6KDrSsdTNfzS227NWyfgnSUBmZHgR+3+TWU
	NDJZ9vVmCyX9pkUQuCiorI23avysspZYfjVlTOwPEUSYGjTC0AIDxj+0BI2PYmyuwRB8
	DZAV9yPoJRgaPLlTcmHW7oEPtKSnbd/AhtruM=
Received: by 10.114.144.1 with SMTP id r1mr13191145wad.97.1217724063167;
	Sat, 02 Aug 2008 17:41:03 -0700 (PDT)
Received: from ?10.59.22.6? ( [210.229.158.224])
	by mx.google.com with ESMTPS id n6sm4310246wag.2.2008.08.02.17.41.01
	(version=SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 17:41:02 -0700 (PDT)
Message-ID: <4894FE95.9030000 at gmail.com>
Date: Sun, 03 Aug 2008 12:40:53 +1200
From: Brian E Carpenter <brian.e.carpenter at gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Alan DeKok <aland at deployingradius.com>
References: <4891B31D.3030003 at piuha.net> <4891C22D.4010807 at gmail.com>
	<4891E183.3070708 at deployingradius.com>
In-Reply-To: <4891E183.3070708 at deployingradius.com>
Cc: Internet Area <int-area at ietf.org>
Subject: Re: [Int-area] discussion of the ISP shared address idea
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: int-area-bounces at ietf.org
Errors-To: int-area-bounces at ietf.org

On 2008-08-01 04:00, Alan DeKok wrote:
> Brian E Carpenter wrote:
>> I don't understand why a customer using Net 10 can't be NATted (at the CPE)
>> into an ISP using Net 10. Since NATs completely separate two address
>> realms, I can't see any reason this would work any differently than
>> by inventing Net10bis.
> 
>   The same thing happens when companies buy other comther companies.  The worst
> I've seen (so far) is 3 layers of NAT, all using Net 10.  It works, and
> it plays hob with equipment trying to have "internal" IP addresses.  But
> hacking selected server equipment is usually cheaper than changing
> hundreds of switches and thousands of end hosts.

>From Shin's answer, it seems that many cheap CPE NATs are broken
in this respect.

However, an ISP that already has a /8 could use it twice in Shin's
scheme, I think, with the CGN between the two instantiations. I don't
see that as more risky than defining a new 'Net 10'. In either case,
leakage has to be prevented by configuration, but in the case I suggest,
the ISP causing a leakage would be the only one to suffer.

   Brian

    Brian
_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area


panies.  The worst
> I've seen (so far) is 3 layers of NAT, all using Net 10.  It works, and
> it plays hob with equipment trying to have "internal" IP addresses.  But
> hacking selected server equipment is usually cheaper than changing
> hundreds of switches and thousands of end hosts.

>From Shin's answer, it seems that many cheap CPE NATs are broken
in this respect.

However, an ISP that already has a /8 could use it twice in Shin's
scheme, I think, with the CGN between the two instantiations. I don't
see that as more risky than defining a new 'Net 10'. In either case,
leakage has to be prevented by configuration, but in the case I suggest,
the ISP causing a leakage would be the only one to suffer.

   Brian

    Brian
_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area