Subject: RE: Draft: PI addressing derived from AS numbers

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Feb 2003 08:44:15 +0200 (EET)

On Fri, 31 Jan 2003, Michel Py wrote:
> > Would it make sense to push Pekka's draft along the experimental
> > track in the spirit of RFC 1797 (the 39/8 subnet experiment)?
> > It may not be an optimal solution, but it would give the
> > community some breathing room while better methods are developed.
> >  I concur with Pekka that sunset provisions are important.
> 
> If a sunset is required, then requesting a "special" 6bone pTLA would be
> the way to go. I don't see what that would buy though, and here's the
> rationale:

Tying this to 6bone is an interesting idea, but the death of 6bone may be
too soon..
 
> The idea behind Pekka's draft is that deployment of IPv6 is being
> hindered because organizations that currently have an ASN are waiting
> for some kind of PI to deploy. Why are they waiting? Because they don't
> want to renumber. Giving these guys a prefix that sunsets does not do
> them any good.

Note that there are other motivations for multihoming than wanting not to 
renumber.

Renumbering _once_, when the mechanism is retired in 5 years (or whatever)  
could be entirely acceptable.

But what they mainly want, as far as I can see is independence and
redundancy; load sharing, performance and policy are just likely secondary
objectives (partially because due to more speficic routes not allowed,
they may be more difficult to do anyway).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Sat, 1 Feb 2003 14:39:33 -0500

> From: "J. Noel Chiappa" <[email-masked]>

    > If an architecture without a namespace which is independent of topology
    > is unacceptable, then people have to either i) radically modify IPv6,
    > or ii) junk it. 

Ah, to make it quite plain what I meant here: by "IPv6" I meant the entire
stack, not just the internetwork level protocol; and by "radically modify
IPv6" I mean to include schemes like 8+8, 16+16, HIP, etc - a system using
one of these is not going to interoperate with one which does not have it
(although I dunno about 16+16).

	Noel

---

From: "Michel Py" <[email-masked]>
Date: Sun, 2 Feb 2003 16:38:01 -0800

Pekka,

>> Michel Py wrote:
>> If a sunset is required, then requesting a "special" 6bone pTLA
>> would be the way to go.

> Pekka Savola wrote:
> Tying this to 6bone is an interesting idea, but the death of
> bone may be too soon..
 
Which is why I am on the side that says the 6bone beginning to shut down
in 2004 is too early. If it is an experiment and/or needs a sunset, why
would NOT it be in the 6bone?

> Note that there are other motivations for multihoming than
> wanting not to renumber.

Of course.

> Renumbering _once_, when the mechanism is retired in 5 years
> (or whatever) could be entirely acceptable.

I am not convinced. If part of the 6bone, then there are reasonable
guarantees that the prefix would indeed be withdrawn. If this was to be
a one-of-a-kind thing, you can be sure that the people that were all for
a sunset will sing another song 5 years later facing renumbering and
will strongly lobby to transform the temporary allocation into a
permanent one.

In other words, I'm all for it if it's part of the 6bone, otherwise I'll
fight it because it will be impossible to sunset.

Michel.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 3 Feb 2003 17:29:52 +0100

> I've sent a short draft (7 pages) to Internet-Drafts for publication.

Which I have not yet read but will do in a short while.

> I propose an automatic allocation of /48, /40 or /32 (based on how the
> community feels) of PI addresses if you have an AS number.
>
> A 16-bit AS number in the range 1 - 2^15, that is.  This is just to 
> enable
> IPv6 multihoming temporarily, until another mechanism is devised, to 
> those
> end-sites that already do it today.  This is kind of a "stop those lame
> excuses now, please" -solution.

Just on the brief description here I like the idea. This would require 
my draft of allowing longer prefixes as well though. Perhaps merging 
the two is a good idea.

>
> Note: personally, I think ASN-PI like this is not a good idea, but 
> it's at
> least better than some others, like breaking aggregates or doing stuff
> like that -- this is controlled, after a fashion.

Agreed.

- kurtis -

---

From: "Michel Py" <[email-masked]>
Date: Tue, 4 Feb 2003 08:13:32 -0800

> Iljitsch van Beijnum
> It is very easy to get an AS number: if you want to
> multihome, you qualify. It's not even very expensive:
> $500

This is very true, and won't be denied by the multiple people that I
know on this list that have ASNs for their _homes_, coming either from
recycled ASNs from mergers or even from flat out requests perverting the
6bone.

Michel.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 Feb 2003 13:27:03 +0100 (CET)

On Mon, 10 Feb 2003, Randy Bush wrote:

> as we had all lived through
> cidr and thought it immensely <polite> ill-considered </polite> to
> think one could do a new addressing design without a *real* new and
> scalable routing design.

Ok, lets see what can be done in this area then.

I'm aware of two ways to make routing scale:

1. Some kind of source routing
2. A hierarchical routing system

The identifier/locator seperation thing is basically source routing.

Current aggregation mechanisms (CIDR) provide some basic hierarchy. But
we should be able to improve on this. The address space is a tree with
the default route at the top and individual hosts all the way at the
bottom as individual leaves. We're not talking about your basic binary
tree here, as many levels are missing in certain parts of the tree. For
instance, below ::/0 aren't ::0/1 and 8000::/1 but (conceptually)
2000::/3, the global unicast space (and some other less interesting
stuff). Below 2000::/3 there are one or two additional conceptual levels
but real routing info starts at xxxx:xxxx::/32, where the "top level
aggregators" live. So essentially we're doing flat routing in the first
32 bits (or rather, 29 of the first 32) of the IPv6 address space. Flat
routing in a part of the tree is not a problem, except that 29 bits is
too many as it leads to a maximum of 512M entries in flat space for this
part of the tree.

So how do we fix this? If we simply introduce a level of aggregation we
could be doing flat routing in a 64k space and then flat routing in
another 64k space. That should work well, especially as the entire space
isn't populated from the start. The trouble is that someone with a /32
must automatically buy transit service from the service provider that
has the /16 this /32 falls in. This means renumbering from time to time.
Also, not much multihoming in this scheme.

Alternatively, we could align the address hierarchy with something else
than the (largely fictional) topological hierarchy. For instance, the
/16s could be allocated to internet exchanges. This way, it's possible
to multihome and shop for transit as many ISPs can provide a path /to/
the exchange and many ISPs can provide a path /from/ the exchange to the
destination network.

Now suppose a node somewhere in the hierarchy fails. A smart
hierarchical routing protocol would repair such a failure by linking
nodes at the level below the failed node to the ones at the level above
the failed node.

Also, a smart hierarchical routing protocol would converge fast by
learning the information it needs to function at the levels it is
present quickly, but then optimize routing by adding additional
cut-through routing entries that bypass the hierarchy if resources
permit and adding this information leads to actual benefits.

Iljitsch

PS. Please no "IXes suck" flaming; if we are actually going to get into
this we can do better but the IX stuff makes for a good example.

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 25 Feb 2003 08:43:25 -0500

> From: Erik Nordmark <[email-masked]>

    > Some form of end-to-end "header compression" can presumably remove the
    > need for the identifiers in every packet

One way to "include" the identifier in each packet implicitly (i.e. make
sure the packets get to the right endpoint) is to include the endpoint
identifier in the transport "pseudo-header", so that you get a checksum
failure if the packet gets to the wrong endpoint.

    > Perhaps providing a reasonably strong binding between the identifiers
    > and locators in some initial packet(s), and having subsequent packets
    > only contain the locators (at least until a locator changes) might be
    > the right model.

I've played with this model some (I even wrote a draft I-D, for the NSRG,
showing how to add this capability to IP/TCP-4; it used the checksum trick
above).

The only problem I recall finding was if you're trying to support mobile
computations (not a big goal of anyone at the moment, I understand :-). If
you pick up a process with an open connection on TCP port X and move it to a
machine which already has an open connection on X, you're kind of hosed. I
hypothesized an small, short, endpoint identifier with scope local to the
destination (I called it an ESEL, for "endpoint selector") to disambiguate
when you have multiple endpoints at a single locator.

	Noel

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 26 Feb 2003 13:33:38 -0500

> From: Brian E Carpenter <[email-masked]>

    > I think that if we were to pursue 4+16 it would exactly cause us to
    > have two namespaces containing different parts of the locator.

"Experience is a dear master, but fools will learn at no other."

    > I did say :-(.

Oh, if you're right, I'm overjoyed! The final nail in IPv6's coffin! Hoorah!

    > (Of course, it's exactly what we have today with NAT.)

Now, now. May I get you a saucer of milk?

	Noel

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 27 Feb 2003 09:19:58 -0500

> From: Kurt Erik Lindqvist <[email-masked]>

    > I was just under the (apparently mistaken) impression that people
    > thought there was some superior architectural advantage with 16+16.

[Not quite sure if your comment relates to 16+16 vis a vis only 8+8, or
to 4+16 as well...]

The advantages of 16+16 over 8+8 are purely deployment ones.

The advantages of 16+16 over 4+16 depend on exactly what flavour of 4+16
you're talking of. If you're talking of the one that Brian glumly forsees as
inevitable, where the location is spread across the two fields, there *is*
an architectural advantage to 16+16.

	Noel