[ppml] Version think... was: alternative to 2005-1

[Owen DeLong]

> 
> Problem: Multi-homing
> In IPv4, multi-advertising (i.e., advertising the same address across
> multiple providers) was the answer to the problem.
> In IPv6, shouldn't we be thinking of multi-addressing (i.e. multiple
> addresses for the same sub-net) as the answer?  ... Granted Shim6 is not
> fully baked yet, but that (or something which accomplishes the same
> basic goal) is where our creative energies should be focused."
> 
Respectfully, I disagree.  Our creative energies should be focused on
finding
a long term solution the fundamental problem which underlies all of these
issues.  The fundamental problem is that we are using IP addresses (v4 or
v6) for two mutually incompatible purposes.  The telephone companies
learned this lesson years ago, solving it with SS7.

	Purpose 1:  End System Identifier

	IP addresses are well suited to the task of uniquely identifying
	an end system on the network.  This task is necessary and beneficial
	in that it allows creation of Access Control Lists and targeting
	datagrams to a particular end node. (Note, I address this from
	a network identity context, not a security identity context).

	Purpose 1a:  Intradomain Routing Locator

	In the intradomain world, routing really boils down to a function
	of end-system delivery, so, the use of the ESI for this purpose
	is compatible.

	Purpose 2: Interdomain Routing Locator

	In the interdomain world, using the entire ESI is non-feasible and
	using a portion of it comes with a number of increasingly difficult
	problems.  What is needed instead is a way to do routing based on
	a separate routing locator token and a corresponding method for
	mapping destination ESIs to Routing Locator at the Interdomain
	edge.

	Focusing our creative energies on this solution will yield the
	greatest benefit overall.

> Problem: ISP lock-in
> In IPv4, PI was the insurance against "my ISP got run over by a truck".
> In IPv6, shouldn't the prudent user (enterprise customer, campus, etc.)
> get addresses from all their service providers?
> 

This is an incomplete definition of the problem.  The true definition
of the problem is:

Changing IP addresses for an entire organization is costly and painful
for a number of reasons:

	+	Readdressing machines takes effort
	+	Machine addresses often appear in configuration data on
		other devices which need to be simultaneously updated.
	+	There is no easy mechanism for identifying all such remote
		configuration data.
	+	Often said configuration data are not under the control of
		the owner of the network being renumbered.
	+	Even when they are, the "flag day" nature of these changes
		creates significant end user impact often taking weeks or
		even months to fully resolve.

It is the nature of end systems to change network topology on a somewhat
regular basis.  In some cases, those changes necessitate a change to the
end system identifier.  In most, they do not, especially in the cases of
end systems which appear in remote configuration data (name servers, VPN
gateways, certain service provider operations hosts, etc.).  In those
cases, the owner will usually take great pains to avoid changing the
ESI unless forced to renumber their entire enterprise.

As a result, fragmentation is the natural order of things, and, efforts
to resist it inflict damage.  Instead, we should be focusing our efforts
on mitigating or eliminating the effects of such fragmentation.

> We need to focus some attention on the effect of fragmentation (whether
> caused by PI or multi-advertising in general) on the Internet routing
> table size.   With the orders of magnitude increases of addresses (IPv6
> vs. IPv4) and AS numbers, there is potential for routing table
> explosion.   It's our responsibility to prevent that.    Even if
> someone's favorite policy goal is not satisfied, addressing policy needs
> to be conservative - and biased heavily against the risk of routing
> table explosion since we have no data about how IPv6 addressing policies
> will impact the Internet over the long term.
> 
Here, I disagree.  Conservative addressing policy as you call it is
inflicting
damage on the internet in one area in an effort to mask damage caused by a
fundamental scaling design flaw in the way we do routing.  The solution
in the long run is to change how we do routing.

Fortunately, most of the tools necessary to accomplish this were designed
into
IPv6 in the form of "Extension" headers.  There is already an extension
header
type 53 defined for routing information.  All that is needed is a new
subtype
for interdomain routing locator token data.  No other changes to the IPv6
protocol are necessary.

Additionally, BGP already exchanges a superset of the information needed to
perform routing on this basis, so, existing BGP can be used until such time
as the new routing paradigm becomes ubiquitous, at which point, we can
make a major reduction in the data exchanged through BGP.

Three new things are needed.

	1.	A mechanism for looking up ESI->RL translations in a secure
		and reliable way.

	2.	Edge Routers will require software capable of inserting RL
		data into packets they are routing.

	3.	Core routers will require software capable of making forwarding
		decision based on RL data first with prefix as a fallback.
		It may be desirable to have RL insertion as part of prefix
		fallback.  Eventually, the prefix fallback capability will
		become unnecessary, but, benign.

All three of these things can be deployed without impacting current routing
and can be deployed on a system by system basis without disrupting
neighboring
systems.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060211/e4f17120/attachment.sig>