Subject: Re: Why is IPv6 a must?

From: "J. Noel Chiappa" <[email-masked]>
Date: Mon, 12 Nov 2001 15:32:34 -0500

> From: "Perry E. Metzger" <[email-masked]>

    >> ??? I said nothing about Mobile IPv6 being a solution to the routing
    >> problem.

    > We were talking about the routing problem. If you just brought it up to
    > be clever (which I assume you did), you didn't further the discussion.

I was merely responding to your (incorrect) initial assertion that:

  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.

I have no interest in discussing the "routing problem". Been there, done that.

(Also, the business of separating identity in location is really not related
to routing. It happens to be a good thing to do on basic grounds, but it does
also make some routing-related things easier. E.g. it can help with
renumbering and dynamic multi-homing; in certain transition schemes for
deployment of new routing architectures it makes the deployment of new
namespaces for location easier; etc, etc.)

    > My own feeling is that we're just going to have to accept the notion of
    > our routers having millions of routes in them and go for algorithms
    > that scale better than distance vector or path vector

There are no such algorithms, and it's highly unlikely there will ever be a
routing algorithm for flat addresses that scales as O(logN), or anything like
that. The only solution to scaling routing overhead is to use
abstraction/aggregation.

	Noel

---

From: [email-masked] (Sean Doran)
Date: Mon, 12 Nov 2001 23:15:38 +0100 (CET)

Geoff Huston writes:

| 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 (*). 

Unfortunately, a view of the universe of AS paths is anisotropic.
Your view and mine differ.   Moreover, your view has benefited from
filtering done by people with closer views of things far away from
you, who then pass along information in a way reminiscent of the
children's game of "broken telephone".   In that game, a complicated
message is whispered from child to child until the last child to
hear the message is asked to try to reconstruct the original message.
The results are often funny.   Try it at home.

While some good comes from "broken telephone" (passing along what
you select, rather than what you hear) in the global routing system,
in the form of information hiding, the grim news is that the atoms
are far from indivisible.   Some split pretty regularly, with a prefix
heard along one AS path at one moment, and then along another -- shorter
or longer, perhaps -- at another moment.   Not to mention the prefixes
which grow (revealing more, often longer AS paths) and shrink (aggregating
which eliminates AS paths).

While it is tempting to consider a message that says, "this AS Path is
invalid for all prefixes", it is not computationally practical to 
compress the on-the-wire message (saving space) in favour of
maintaining an association between AS paths and prefixes (requiring
space and/or computation), and dealing with prefixes which share
AS paths but which do not share other attributes (e.g. communities,
or in some implementations, origins).  

Moreover, it would be another example of overloading of the AS path,
which is already used as a funny sort of metric as well as an announcement-
loop-prevention mechanism.   Using it as a tag to consolidate
reachability information may not seem soooo different from AS-path
filtering (e.g., ignore ^3561 174_), but such filters are static
and local, and really are used to constrain metric-exploration in
the event of a failure (of e.g. ^174_, which we don't want to try
to find behind 3561 when the direct link(s) fail).

| there are other ways to look at the network that also provide 
| some tractable level of grouping that could make interdomain routing scale. 

That's good to know, but I haven't seen them described that I remember.
Do you have pointers, please?

| 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.

I think you are trying to say that it should be possible to
use a lookup on the IP (whatever v number) address and find
some description of a location in the network.   This is
a good idea, and is part of separating location and identity,
but unfortunately you would have to do the lookup at each
hop, or throw away the hop-by-hop model and use "aggregate flows"
along the lines of MPLS LSPs (or some other tunnel/map-and-encap system),  
or rewrite the addresses into a form that does not need
to be looked up at subsequent hops (but which can be rewritten
back to the original form at/near the destination), along the lines
of 8+8.  Note that I ranked those three options by increasing amount
of difficulty of implementation and operation, from my perspective.

| * Your mileage may vary.

My mileage is kilometreage. :-)

	Sean.

---

From: [email-masked] (Sean Doran)
Date: Tue, 13 Nov 2001 00:43:21 +0100 (CET)

Perry Metzger writes:

| Ah, but then what's your method for mapping between the two, and how
| fast must *it* run and how well does *it* scale? 
...
| I'm not saying such a thing doesn't exist. I'm just saying that I
| haven't seen a worked example I can believe in.

Stay tuned to multi6.   

We are in the process of describing the requirements and the way
IPv4 site multihoming works today precisely enough that the various
proposals that have been mooted can be adapted to support some 
superset (ideally a proper one, if possible) of those.

Please feel free to try to make sure your excellent questions and
concerns are reflected in the requirements document.   The draft
authors/editors are happy with input, and of course so are the WG chairs.

If the reqs document ends up providing a means of determining
whether a given proposal is something you can believe in,
everyone in this standards organization should be very happy.

	Sean.

---

From: [email-masked] (Sean Doran)
Date: Tue, 13 Nov 2001 00:54:57 +0100 (CET)

| Who says you need to use the IP addresses for that purpose? There is
| plenty of precedent -- for a a long time we've had this notion of the
| routing protocols adding labels on that had nothing to do per se with
| the IP address. See the "AS" notion, for example, in which we label
| various clouds with AS numbers, which are never seen by end users. It
| would be straightforward enough to build a labeling scheme that was
| used inside the routing protocol that stayed inside the routing
| protocol. You could happily label the nodes of the routing cloud with
| whatever numbering/labeling scheme you like.

Map-and-encap systems can work quite well; it's mostly a question
of making sure the various mapping points can coordinate with various
things (and each other), and making sure they can cope with 
the map-encap-decap-process operations they have to perform.

One of the systems you have rubbished in this thread is
heavily influenced by, and even reliant upon, map-and-encap,
and several smart people believe it would work OK.

Peter Lothberg (whom I find myself agreeing with alot) is
the progenitor of an interesting map-and-encap system which
allows for (among other things) separating end-to-end identity
from topological location.

Unfortunately, map-and-encap systems can also be like MPLS...

Anyway, if you are going to use the same encapsulated
payload and are going to have a common globally unique
identifier inside that payload, why not integrate the inside
and outside headers, rather than use encapsulation and
information pull-up/push-down, which are inevitably more expensive?

Again, Peter once proposed putting a stack of MPLS-style labels
(or IPv4 addresses, a la LSRR) into the first bytes of an 8+8-like system.
You will see more of this later.

| In other words, v6 has neither helped nor hurt the routing problem --
| it is orthogonal.

Well, yes, that's what we've been saying all along!

	Sean.

---

From: [email-masked] (Sean Doran)
Date: Tue, 13 Nov 2001 16:31:18 +0100 (CET)

| However, to come up with an architecture which has separate concepts of
| identity and location, there can't be any direct relationship between them
| at all (other than mapping through some kind of database).

Well, it's sufficient to have the identity not be dependent upon the 
location.   The location may be dependent on the identity without
much pain.  For example, all 128 bits of an IPv6 address field could
be considered the locator, but only about half of those form the
identity.  So the host only considers those identity bits when
(for example) encoding its address on the wire or demultiplexing
packets for itself (performing checksums etc.).

The one-way dependency makes a few things easier.  For example, if
a host or an agent in the middle has a scheme for generating/looking-up 
some or all of a locator based on the host's identity bits.

It is, however, probably a bit cleaner and more flexible if we have
full independence, such that "inside" & "outside" location labels
can vary only on the basis of where the traffic is sourced/sunk
in the network, rather than what host is doing the talking or listening.

Either way you are stuck with a flavour of registering your 
identity at a particular location.

| Mobile IP neither is, nor pretends to be, any kind of demonstration of
| a model with separate ID and location spaces.

If something sending to the mobile node thinks it's talking to
"mobile node registered at home node", but will also talk with
"mobile node registered at secondary home node" without much
fuss, you have a separation of identity ("mobile node") from
location ("home node" or "secondary home node").

If the receiving "mobile node" chooses to accept packets 
for "mobile node" independent of whether it is registered
at "home node" or "secondary home node", you have an analogue
to an 8+8 scheme where only the lower 8 identity bytes are
used in checksumming/demultiplexing by the receiver.  The top
8 bytes likewise are an analogue to "home node" or "secondary
home node".   

	Sean.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 12 Nov 2001 22:09:14 -0500

In message <[email-masked]>, "Perry E. Metzger" writes:
>
>"J. Noel Chiappa" <[email-masked]> writes:

>
>My own feeling is that we're just going to have to accept the notion
>of our routers having millions of routes in them and go for algorithms
>that scale better than distance vector or path vector so we don't
>drive them into the ground while doing the computations. We can't get
>rid of the desire to have huge numbers of routes so we have to find
>ways to avoid nuking ourselves when we have huge numbers of routes. It
>would be nice if we could come up with the perfect new architecture
>but no one has yet designed it.

More to the point, no one even knows if such a system is designable.
If we stick with the current addressing model -- v4 or v6 -- we either
have to *enforce* topological addressing (with all that that implies
for the fate of multi-homing), or we have to hope for a fundamental
breakthrough in routing algorithm design.  Lots of us would love to "go
for algorithms that scale better" -- but we don't know how to.  It's a
research project, i.e., we don't know the answer and we don't know when
(or if) we will know it.

During the IPng directorate, there was a fair amount of interest in
designs that separated locators from addresses.  It was argued
intensely, but in the end there was no consensus to move in that
direction.  For lots of reasons, I think that that was the wrong
decision, but we're pretty much stuck with v6 as defined.  The question
is how to move on from here -- and I hope that the road ahead works,
because we *really* need the extra address space.

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com

---

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Nov 2001 22:19:19 -0800

> does the rendezvous location really have to be the "original topological
> location" of the host or is that just how folks started thinking about it?
> 
> and given that the rendezvous location has to be somewhere in the network,
> how can we get around the problem that that location might become 
> unreachable no matter where it's located?   I mean, you could replicate 
> the information to multiple sites and use anycast to find a location, but 
> would this fundamentally change the mobile IP protocol?

How would you do this such that you did not further aggravate route 
scaling problems?  If you do it with mobile-ip and anycast, would that 
would require such mobile addresses having either additional IGP or 
(worse) BGP paths?

On the other hand, if you have the rendevous be a database that maps some 
sort of a name to an IP address you do not perturb the routing system and 
you impose the overhead on those who are mobile, and their agents.  It 
requires a model without TTLs but initialization and active notification. 
  Whether this can be done is questionable and a valid topic of research 
(a bunch of us have been questioning for a while ;-)

Eliot