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

["Tony Li" <Tony.Li@procket.com>]

Tony,

|   > 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.
|   
|   That will work for some companies with limited application 
|   needs, but
|   for others nat is a non-starter. 


Sorry, I should have been more clear.  No, I'm NOT trying to
sell NATv6.  

My point is that when the external locators are configured in
a very small number of places and internal addressing is independent
of external addressing, renumbering is very simple.  In 16+16,
I'd propose that the external locator be only in the border router.


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


Hmmm...  why?  The only thing that the border router does is
to add or remove the locators from the L3 header.  Access 
lists should be operating on the identifier, not the locator,
correct?


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


Ok, but do we need actual perfect uniqueness?  Or just 'pretty close'?
Operationally, 'pretty close' is a whole lot easier.


|   > I submit to you that if folks are unwilling to change to an
|   > architecture that scales, then IPv6 is already doomed.
|   
|   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. 


Well, if the changes are confined to the routers, then that
pretty much precludes transport changes and DNS changes.

I guess we're done.


|   > 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.
|   
|   That is the same argument that was used to structure the 
|   locator part
|   according to provider hierarchy ... ;)


Umm...  I don't see that at all.  But maybe I'm just not getting your
joke.

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


Yes, someone could masquerade with someone else's identifier.
However, doing a lookup on the identifier should return the locators
for the correct host, not the imposter.

Tony