Subject: Re: Why is IPv6 a must?

From: Eliot Lear <[email-masked]>
Date: Wed, 07 Nov 2001 16:14:17 -0800

>Actually, the engineering cost of building IPv6 into operating systems
>is already essentially paid.  The cost of building it into routers and the
>like
>is paid.  The vendors are all (basically) IPv6-ready.

Valdis,

Your message is generally well put.  However, while it is possible to send
the packets on the wire, the fundamental underlying scaling point, the
routing system, has not been properly addressed.  Perhaps a solution can be
retrofitted in, but then again, who knows?  This, I thought, was <largely>
the point of multi6.

Eliot

---

From: Bill Manning <[email-masked]>
Date: Wed, 7 Nov 2001 21:28:26 -0800 (PST)

% >Actually, the engineering cost of building IPv6 into operating systems
% >is already essentially paid.  The cost of building it into routers and the
% >like
% >is paid.  The vendors are all (basically) IPv6-ready.
% 
% Valdis,
% 
% Your message is generally well put.  However, while it is possible to send
% the packets on the wire, the fundamental underlying scaling point, the
% routing system, has not been properly addressed.  Perhaps a solution can be
% retrofitted in, but then again, who knows?  This, I thought, was <largely>
% the point of multi6.
% 
% Eliot

	Hum... I thought that multi6 was trying to figure out the ramifications
	of multihomeing w/ IPv6.  The issues wrt the routing system really
	need to occur in a WG devoted to better routing protocols, not one
	with a focus on multihoming.  at least IMHO... 

-- 
--bill

---

From: Joe Abley <[email-masked]>
Date: Thu, 8 Nov 2001 00:56:23 -0500

> 	with a focus on multihoming.  at least IMHO... 

multi6 is trying to agree on a strategy for multi-homing in IPv6
that meets a set of requirements. Amongst those requirements (in
the current, outdated draft, which we are hurrying to improve) is
this:

3.2 Additional Requirements

3.2.1 Scalability

   Current IPV4 multihoming practices contribute to the significant
   growth currently observed in the state held in the global inter-
   provider routing system; this is a concern both because of the
   hardware requirements it imposes and also because of the impact on
   the stability of the routing system.  This issue is discussed in
   great detail in [9].

   A new IPv6 multihoming architecture should scale to accommodate
   orders of magnitude more multi-homed enterprises without imposing
   unreasonable requirements on the routing system.

Hence, we hope to identify a solution which scales better than the
hole-punching antics common in IPv4.

So, Bill is right; scaling the routing system is not in the list
of objectives in multi6. However, if we find a good solution to
multihoming, we may be able to eliminate a big contributor to the
amount of state held in the routing system, and in that way reduce
the urgency of finding a scaling solution.

Joe

---

From: Keith Moore <[email-masked]>
Date: Thu, 08 Nov 2001 08:19:34 -0500

> retrofitted in, but then again, who knows?  This, I thought, was <largely>

seems a bit of a stretch to claim that the routing scalability problem
can be solved if we can only find another way to provide multiple routes
to a destination network.   

Keith

---

From: Geoff Huston <[email-masked]>
Date: Mon, 12 Nov 2001 06:40:23 +1100

>retrofitted in, but then again, who knows?  This, I thought, was <largely>

Scaling of the routing system is not the objective of multi6 - multi6 is 
working on the principle of attempting to do no harm to the scaling 
properties of the routing system while allowing complex edge connectivity 
scenarios.

Generally, scaling of the routing system requires the elimination of 
information from the routing domain. And, generally, the best you can do 
here is attempt to align deployment with some structural property of the 
syntax of the protocol elements you are using as routing objects, and 
eliminate information through aggregation of the routing objects 
(aggregateable address hierarchies). The alternative is to re-evaluate the 
routing domain and select some other attribute of the domain that does not 
have the same population / complexity / growth and attempt to route based 
on this attribute.

I'm unsure what IPv6 has to do with this - it seems to make the task of 
scaling routing about the same as it is in IPv4 - there appears to be no 
intrinsic property of the protocol that alters the situation to any 
appreciable extent.

   Geoff

---

From: "Perry E. Metzger" <[email-masked]>
Date: 11 Nov 2001 22:09:31 -0500

Geoff Huston <[email-masked]> writes:
> I'm unsure what IPv6 has to do with this - it seems to make the task
> of scaling routing about the same as it is in IPv4 - there appears to
> be no intrinsic property of the protocol that alters the situation to
> any appreciable extent.

There is a school of thought that seems to believe that IPv6 is a
failure because it only solves a quite narrow although extremely
important problem -- specifically address space exhaustion.

The fact that it does not solve the global routing table meltdown is,
according to such people, an obvious failure of v6 -- never mind that
they are unrelated issues. As you note, there is no distinction
between solving the global routing problem in a v4 or v6 context. The
same algorithms can be used for either. If new algorithms are
developed, they can be deployed for either.

--
Perry E. Metzger		[email-masked]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/

---

From: Randy Bush <[email-masked]>
Date: Sun, 11 Nov 2001 19:55:45 -0800

> they are unrelated issues.

addressing and routing are intimately related, inextricably intertwined,
etc. etc.

randy

---

From: "Perry E. Metzger" <[email-masked]>
Date: 11 Nov 2001 23:06:38 -0500

> addressing and routing are intimately related, inextricably intertwined,

Of course. However, we only know one way to do addressing right now,
and it is the same paradigm in v4 and v6. People frequently propose
"endpoint identifiers" and "routing identifiers" be separated but no
one has ever come up with a worked proposal that was less flawed than
the current mechanism.

In any case, anyone who doesn't propose dumping v4 because the
addressing is "wrong" should have no trouble with the way that v6
addressing is done in general.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 11 Nov 2001 23:12:14 -0800

Perry & Geoff,

Quite simply, a bunch of us *are* searching for a paradigm shift.  Geoff's 
good work in this area reveals the complexity of the whys and wherefores of 
the routing system.  Given that 8+8 was a serious consideration (and to 
some deserves some amount of revisiting -- at least as a starting point), I 
don't believe we can say that the deployment of v6 is completely divorced 
from the routing system.  8+8 is merely an existence proof of how the 
routing system and v6 can be intertwined, for better or worse.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Nov 2001 08:39:54 -0500

> Quite simply, a bunch of us *are* searching for a paradigm shift.  

Indeed.  But a satisfactory one hasn't been found yet.  

Keith

---

From: "Perry E. Metzger" <[email-masked]>
Date: 12 Nov 2001 09:42:30 -0500

> Indeed.  But a satisfactory one hasn't been found yet.  

And, absent one, we have to keep making the net work.

By the way, if the rate of v6 adoption is any indication, v6 is doing
very healthily indeed. It isn't obvious to the greater world, but it
has almost certainly hit an exponential growth phase. Yes, we're still
talking about an infinitesimal fraction of the number of users v4 has,
but I now find it routine to discover that mail or http or ftp
connections to a host I've never heard of before are going over v6
when it used to be a thing that only happened deliberately. There are
a couple of orders of magnitude more users than a year ago -- I'm
going to work on some estimates of numbers and the growth for a talk
I'm giving in December and I'll post them here when I have them.

---

From: Geoff Huston <[email-masked]>
Date: Tue, 13 Nov 2001 07:24:11 +1100

>good work in this area reveals the complexity of the whys and wherefores 
>of the routing system.  Given that 8+8 was a serious consideration (and to 
>some deserves some amount of revisiting -- at least as a starting point), 
>I don't believe we can say that the deployment of v6 is completely 
>divorced from the routing system.  8+8 is merely an existence proof of how 
>the routing system and v6 can be intertwined, for better or worse.

As I tried (probably poorly) to indicate in my last posting on this topic 
there are a number of different directions you can take when searching for 
a lever to use to handle scaleable routing. Our recent experience with V4 
using an address-based hierarchy tends to indicate that the hierarchy leaks 
- i.e. attempting to align the structure of the network into a hierarchy 
and aligning addresses to conform to this same hierarchy is not an easy 
task and it tends to break down in the face of increased interconnectivity 
at the edge (multi-homing) and in the middle (peering and multi-transits). 
If you look away from an address -based hierarchy and define other objects 
as the 'atoms' of a routing system then there may be some benefit. Even 
today, with some 105,000 objects in the routing table (*) there are only 
some 12,000 AS's (*) and 15,500 AS paths selected (*). This tends to 
indicate that grouping addresses not by bit boundaries, but by origin AS's 
has some potential, in my view (*). If you take this AS-based perspective 
the issue of V4 / V6 tends to be less important than if you take an address 
hierarchical perspective. I note the AS-based approach to hierarchies as an 
example - there are other ways to look at the network that also provide 
some tractable level of grouping that could make interdomain routing scale. 
The point is that the degree to with the inter-domain routing issue is 
intrinsically liked to the address structure within the protocol depends on 
the approach used by routing. Some approaches, like an AS-based approach, 
attempt to bypass an effort to structure the address space as the 
aggregateable element of the routing system, and the corollary is that the 
approach has pretty much the same leverage in a V4 world, a V6 world, or a 
heterogeneous world.

    Geoff

* Your mileage may vary.