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

["Tony Hain" <alh-ietf@tndh.net>]

Tony Li wrote:
> 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.

I have looked, but can't find a reference to the 16+16 draft, please
send a pointer so I can get into the context.

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

Once we figure out how to verify that the indetifier is really unique.

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

For RFC3041 addresses, the argument is that they are 'very close' to
unique, but we still require backing that up with DAD to minimize
confusion when collisions do occur.

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

If a 5-10 year solution is what we really need, now is the time to
start. At the same time, I suspect we are a couple years from an IRTF
result that will take a few more to work through the IETF, so the
dev/deployment cycle can start. While that is working its way through
the system though, we need to find a way to fit an expanded set of
multihome sites into the existing mechanisms. 

My approach has been that we draw a line between those that need to be
in the global table for business/policy reasons, and those that are
looking for local alternate service. We aggregate the latter group
through exchanges, and simply eat the pain of the first group. This
becomes a self correcting situation when financial feedback is applied
to the number of prefixes that get injected into the global table. 

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

We need a system for doing those lookups that scales without imposing
limitations on movement. 

Tony