Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

From: "Tony Li" <[email-masked]>
Date: Sun, 3 Nov 2002 00:03:35 -0800

Tony,

|   The IETF consensus process != democratic, and rarely comes 
|   close. The
|   point was more to make sure there is someone that can give 
|   a first-hand
|   defense of the requirements so they are not easily 
|   dismissed by those
|   with other priorities.

That is certainly fair and welcome.

|   Yes, we are here to focus on layer 3 scaling, but we can't 
|   loose sight of the wider impact.

Please remember that my interest is the growth of the net as a whole,
not just scalability.

|   > The end
|   > user is going to have a prefix that reflects their topology,
|   > even in the single homed case.  If we can do the renumbering
|   > only at the border and reduce renumbering costs that way, does
|   > the end user still care what his prefix is?
|   
|   That question deserves a firsthand answer from a current enterprise
|   network manager. 

So it may surprise you to learn that I used to be a network operator
some time ago [Los Nettos, 1987-1990] and an enterprise network manager
for my company and of course my own home.  We happened to recently change
providers at my company and, because we are behind a NAT system, found
the change to be quite trivial.  Of course, we only needed to renumber the
NAT box.

In a 16+16 environment, where only the border routers are configured with
the global locators for the enterprise, renumbering amounts to reconfiguring
only one system.

|   But since there is no way to ensure that an identifier is globally
|   unique, the only way to accomplish the goal is to couple them to
|   describe 'this identifier at this location'. If the location is not
|   stable, the static description is not stable. 

You can assign an identifier based purely on the administrative hierarchy.
We have an existance proof that we can do this, because we've done so 
already in DNS.

|   > |   This model was probably possible 4 years ago, but at this 
|   > |   point I doubt
|   > |   tweaking the pseudoheader can even be on the table. 
|   > 
|   > 
|   > Why?
|   
|   Shipped code is hard to change. For something as 
|   significant as this, it
|   takes two years from the point of agreement to get new code shipped,
|   then it takes an additional 3-7 years to get the prior code 
|   retired. We
|   will need a multi-homing solution well before that, so we 
|   need to find
|   something that is incremental.

I submit to you that if folks are unwilling to change to an
architecture that scales, then IPv6 is already doomed.

|   Because the identifier is not stable & globally unique, and 
|   even if we
|   had a way to ensure that, the privacy advocate's alarms 
|   would be going
|   off. Despite the desire to avoid it, the current reality is that to
|   create a globally unique identifier we bound the problem by 
|   coupling it
|   with its locator.

That is certainly true today.  However, there is no requirement for
that.  Consider that host foo.cisco.com already has a globally 
unique and fixed hostname.  We allocated this in a hierarchical
fashion that requires no aggregation.  We simply do the same for
the identifier space.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 4 Nov 2002 15:18:53 -0800

Tony Li wrote:
> ...
> for my company and of course my own home.   

That does not surprise me, most people that really understand
inter-domain routing have arrived from the school of hard knocks. The
point I was trying to make is that the reasons behind deployments today
might be different from those we used 10+ years ago, so we could use a
first hand answer to current demands.

> We happened to recently change

That will work for some companies with limited application needs, but
for others nat is a non-starter. 

> the global locators for the enterprise, renumbering amounts 

Well, for the general case that one 'system' needs to include the border
router, dns, firewall, ids, partner access lists, etc...

> We have an existance proof that we can do this, because we've done so 

In fact we have an existence proof in both DNS & IEEE EUI that
inadvertent & intentional duplication happens. So those mechanisms can't
be used as 'globally unique' identifiers as they are. If we add some
cryptographic properties, we can probably improve that.

> ...

If the changes are contained to the routers, the timeframe is reduced
from 7 years to 3. In any case a drastic change will take two years to
get vendor shipments and another year for service providers to deploy. 

> fashion that requires no aggregation.  We simply do the same for

That is the same argument that was used to structure the locator part
according to provider hierarchy ... ;)

That aside, until we get DNSsec widely deployed there is nothing that
prevents someone from injecting foo.cisco.com into a remote part of the
tree. The only way we can consider a bit string to be a globally unique
identifier would be to have some cryptographic property that could be
checked in real time. I am not opposed to such a system being created,
but holding IPv6 multihoming hostage until it exists would be a
disservice to those who need expanded multihomed address space now.

Tony