Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)

[Keith Moore <moore at cs.utk.edu>]

Noel Chiappa wrote:
>     > From: "Stephen Sprunk" <stephen at sprunk.org>
>
>     > .. ULA-C/G leaks will not collide with each other. This means that,
>     > unlike RFC1918 which is _impossible_ for ISPs to route for multiple
>     > customers, ULA-C/G routes _can_ be routed publicly. Any prohibition
>     > on doing so by the IETF or RIRs can (and IMHO, will) be overridden by
>     > customers paying for those routes to be accepted.
>
> Which would argue that the only realistic way to make *absolutely certain*
> that IPv6 "private" addresses truly *cannot* be used out in the 'main'
> internetwork is to allocate the same ranges of addresses to multiple
> parties.
>   
Perhaps, but then we end up with all of the problems associated with
ambiguous addresses, and we lose all of the advantage of IPv6.
> Anything else is just PI with a few speedbumps, and a different label.
>   
Maybe, maybe not.  In practice, today, not every IPv4 address prefix is
PI.  Today, the length of your IPv4 prefix has some influence on whether
your prefix gets advertised.  There may not be an absolute boundary, but
there is a barrier nonetheless.  So I can certainly imagine that it
would be harder to get ULA prefixes as widedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IY3EG-0006px-Rj; Wed, 19 Sep 2007 13:20:49 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IY3EF-0006pr-38
	for ietf at ietf.org; Wed, 19 Sep 2007 13:20:47 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY3EE-0006ml-O1
	for ietf at ietf.org; Wed, 19 Sep 2007 13:20:47 -0400
X-IronPort-AV: E=Sophos;i="4.20,274,1186383600"; d="scan'208";a="18885697"
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com)
	([172.19.96.182])
	by sj-iport-1.cisco.com with ESMTP; 19 Sep 2007 10:20:46 -0700
Received: from 64-142-29-214.dsl.static.sonic.net ([10.82.210.28])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l8JFvd6Z014054;
	Wed, 19 Sep 2007 08:57:40 -0700
Message-ID: <46F15AA1.7010806 at cisco.com>
Date: Wed, 19 Sep 2007 10:21:37 -0700
From: Michael Thomas <mat at cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Keith Moore <moore at cs.utk.edu>
References: <11452.1189607641 at marajade.sandelman.ca>	<61769.1189616824 at sa.vix.com>	<3009e5840709121107o78cdd94fu907ab4de187b5d78 at mail.gmail.com>	<46E90E04.30000 at piuha.net>	<0F18F924-0B75-4F7C-9DCF-2759E9CECB61 at cs.ucla.edu>	<46EDFEC0.4060308 at piuha.net>	<07ea01c7fa05$e68ae030$b3a0a090$ at net>	<p06240600c315a807196a at [98.207.7.244]>	<42439.1190137947 at sa.vix.com>	<46F04CCE.6010503 at cs.utk.edu>	<40387.1190163044 at sa.vix.com>	<46F0802F.2020504 at cs.utk.edu>	<67372.1190167400 at sa.vix.com>	<46F08E48.3010105 at cs.utk.edu>	<96049.1190173469 at sa.vix.com>	<46F0B1F3.1040608 at cs.utk.edu>	<30720.1190180540 at sa.vix.com>	<46F0BB6B.7050601 at cs.utk.edu>
	<11902.1190215657 at sa.vix.com> <46F14986.1080808 at cs.utk.edu>
In-Reply-To: <46F14986.1080808 at cs.utk.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1260; t=1190217460;
	x=1191081460; c=relaxed/simple; s=oregon;
	h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; 
	d=cisco.com; i=mat at cisco.com;
	z=From:=20Michael=20Thomas=20<mat at cisco.com>
	|Subject:=20Re=3A=20ideas=20getting=20shot=20down |Sender:=20
	|To:=20Keith=20Moore=20<moore at cs.utk.edu>;
	bh=UItTQN4VZjHkTWER6mH2byz+Y4z0pzhLPtvT/nyqgA4=;
	b=bw58T+nIicJICPwYwtWuFMJY8hB5Mfze/IsjIr6Vcp3Pgv23FfntaTFkdmmA0v9REY10bPdo
	ifuaVK50KgY+BKC4c4+dWXkkrHBLTUsnpMx/wYnzAJyq50hAXr7ehxo5;
Authentication-Results: imail.cisco.com; header.From=mat at cisco.com; dkim=pass (
	sig from cisco.com/oregon verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 'IETF Discussion' <ietf at ietf.org>, Paul Vixie <paul at vix.com>
Subject: Re: ideas getting shot down
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org

Keith Moore wrote:
> Paul Vixie wrote:
>   
>
>> which is why i'm proposing a standard of "demonstrable immediate harm" rather
>> than the current system of "that's not how you should do it" or "that's not
>> how i would do it".
>>   
>>     
> That's the wrong standard, it sets the bar way too low.  IETF shouldn't
> endorse anything unless it has justification to believe it is good; IETF
> should not discourage anything unless it has justification to believe it
> is bad.   And that justification should come from engineering analysis
> (or measurement, if it's feasible).  Sadly, a lot of people in IETF do
> not have engineering backgrounds and don't understand how to do such
> analysis.  This is something we need to change in our culture.
>   

Feh, ly advertised as PA
prefixes.  How much harder, I cannot say. 

So the speedbumps might be useful.  But people wanting to absolutely
forbid any ISP from advertising a ULA prefix will probably be
disappointed.  That doesn't bother me, because I don't think it's
necessary to have that absolute prohibition in order for networks to
push back on routing table size and routing complexity.  

Sooner or later, routing scalability will be a problem in IPv6.  When
that happens, each network will pick some means to decide which prefixes
get advertised within its network and which get filtered.   It's not
rocket science to guess that networks will favor their own customers,
the networks with which they have explicit agreements, and the networks
from which their customers derive the most value.   That probably puts
most ULAs and PIs fairly far down in the preference list.


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf







that seems awfully self-important to me (where "self" == "ietf").
"The IETF" (putting aside that it isn't a hive mind) isn't the ultimate
arbiter of good and bad, or useful/useless. Often there is utility to the
notion of "if you're doing to do this questionable thing, at least do this
questionable thing consistently". What you're advocating toes the best
is the enemy of the good line. Nothing would make the IETF
irrelevant faster than crossing that line.

       Mike

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf