Subject: Re: Enforcing unreachability of site local addresses

From: Dan Lanciani <[email-masked]>
Date: Sat, 1 Feb 2003 15:51:21 -0500 (EST)

David Conrad <[email-masked]> wrote:

|On Saturday, February 1, 2003, at 09:35  AM, Dan Lanciani wrote:
|> I was actually referring to the practice of inserting 48-bit (or even 
|> 64-bit)
|> hardware identifiers into the address in the name of easy 
|> configuration.
|
|One allocation mechanism is pretty much as good as any other.  Doesn't 
|matter how those 48  or 64 bit numbers are allocated, the EUI registry 
|would be fine.

That isn't clear.  There are certainly cases where we will want to number
an interface for which we do not already have an EUI from the hardware.  If
the entire identifier space is already taken up with EUIs then there is no room
for someone to get a block of identifiers for non-EUI applications.  I admit
I haven't looked into this; what does it take to get an EUI-64 allocation?
I assume that to get any EUI-48 space you still have to buy an OUI at a fairly
high price (or else buy old Ethernet cards to hold as tokens).

|> I would not want to depend on the edge router's having that kind of 
|> knowledge
|> of the locator routing system just to make multi-homing work for other 
|> sites.
|
|Hmmm.  Multiple ways to solve this, of course.   E.g.: the source edge 
|router does a lookup, gets back a bunch of locators.  A naive 
|implementation could simply pick one and forward to the core via 
|default.  Getting back a network unreachable could trigger the naive 
|implementation to pick a different locator.  The more elaborate the 
|edge router gets in terms of routing system knowledge, the more 
|effective the multi-homing would be.

Again, I'm not thrilled with making the effectiveness of multi-homing depend
on the participation of other sites' routers in the low-level routing (locator)
system.  I would prefer to add more at the identifier level, but this is really
a minor quibble.

|> I'm not sure what you meant by forwarding.
|
|The old destination edge router gets a packet for an end point 
|identifier that has left the network the old edge router is responsible 
|for.  The old edge router does a lookup of the destination identifier, 
|gets the new locator (if it doesn't already have it), and forwards to 
|the new edge router.  It would need to do this for the TTL of the old 
|locator.

Yes, definitely not what I meant by short-circuiting. :)

|It would.  The reason I favor the edge router approach is that I wanted 
|something that would work with IPv4 as a transition aide...

I'm still not sure I see why it wouldn't work.

|> Whether we really want to help perpetuate
|> the current archaic routing system by building a layer like this is 
|> still open
|> to debate.  Clearly adding a layer is better than doing nothing; 
|> however, I'd
|> like to think that we can ascertain a pure routing solution that is 
|> isomorphic
|> to the split solution.
|
|Baby steps...

Perhaps, but this is really what got us into the mess we are in today.  What
was meant as a crutch to keep memory-address-bit-deficient hardware viable
for a few extra months/years has become a serious dependency problem.  By
turning addresses into almost-routes aggregation has allowed routing protocols
that were obsolete years ago to remain in use, but end users pay the terrible
price of having their addresses tied to topology.  Like any addiction, this
problem will only get worse as we continue to feed it.

So, yes, I'm all for a translation layer if it is the best that we can do and
if we can do it at all.  But since we almost certainly can't do it all in the
face of current politics, I might as well dream about fixing routing...

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Feb 2003 16:11:31 +0100

David Conrad wrote:
> 
> Brian,
> 
> On Wednesday, January 29, 2003, at 02:33  AM, Brian E Carpenter wrote:
> > If we achieve stable locators, this problem largely goes away,
> > but stable names in themselves are insufficient IMHO.
> 
> The problem isn't the DNS, but the concept of 'stable locators'.  Given
> the need to aggregate, you simply can't have stability in locators if
> network topology changes.  

Yes and no. That's to say that on certain assumptions (i.e. the
assumptions built into map+encap, 8+8, GSE, and MHAP) you can have
a much more stable locator than today. Such locators are stable under
a variety of *localized* topology changes, but not all of course. I 
should have made it clear that is what I meant. (I think the Tony Hain
flavour of PI would also have a similar degree of stability.)

> Since locators need to change when topology
> changes, any solution you come up with will need to deal with
> propagation delay and security while at the same time dealing with
> scalability and performance.  I would argue that the DNS can be
> contorted to deal with these requirements (although whether or not
> you'd want to is another question).

Indeed. My view is that chances of suitably contorting DNS are
much greater with the relatively stable locators I am thinking of.

    Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 4 Feb 2003 11:03:31 +0100

>>> Assuming? Hello? This exactly what PI is. If there is no central
>>> routing
>>> it's not PI anymore. PI is what we have _today_.
>>
>> Exactly. And today we don't have a billion routes.
>
> Fortunately enough, if you would like the routing algorithms to
> converge in real time.
>

I rather come up with a solution to todays problems so we get time to 
work on tomorrows. If we aim for a 100% solution now, we will never get 
there.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 4 Feb 2003 15:12:18 +0100

>> but even if we in San Fransisco would agree on a new routing model,
>> it would still take us at least 3-5 years to implement.
>> See the migration to BGP4 as example.
>
> 5 years is overly optimistic, IMHO.

Probably.

>> I say go for /48 PI space. Take a /16 (or something suitable) and
>> divide it per RIR, and use it as PI space.
>
> This is way too risky. Potentially, 4 billion routes. I agree that we

The 4 billion routes is a figure out of thin air. Let's solve todays 
problems first, and the we start worrying about the future.

> don't have a problem in the short term. Until we get to 50k routes
> nobody cares.

I am more worried about ever reaching 1k, or 10k....

> But, doing this would put research efforts to a halt. 10 years down the

On the contrary. It will buy us time and give us experience. I still 
argue that we are looking at solutions to a problem we still have not 
understood. I am not convinced that all DLS subscribers and PDAs won't 
PI space and multihoming. Multihoming comes at a cost. IPv6 in it self 
will come at a higher cost. Let's see who is willing to pay first.

> road, suddenly we have 500k BGP 4+ and the Internet craps out. I don't
> want to be the guy that recommended that we re-create the IPv4 swamp,
> because this is exactly what we are talking about.

Yupp. That is the advantage. We can take the same policy, and learn. No 
need for implementations or arguments over assignment policy.

> 10 or 15 years ago, we gave away swamp space to anyone that wanted it
> because nobody thought that it would ever have a scalability issue. 4

I wasn't around then, but from what I have been told and read I think 
everyone was very aware of the scaling issues. But decided to put them 
forward and buy time.

> billion /48 prefixes in the global routing table, what do you call 
> this?
> I call it IPv6 swamp.

It is! No question, but do you want to wait 5+ years?

- kurtis -