[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: draft-kurtis-multihoming-longprefix comments



Eliot Lear wrote:
> ...
> Your initial comment related to enterprises.  Enterprises 
> don't change 
> providers all that often.  

'Often' is a function of your perspective of time. Even if they don't
meet your definition of often, they want the ability to move at a
moments notice without the threat of a significant cost hanging over
their heads.

> But even if they did, we have the tools to 
> readdress devices in IPv4 -- it's called DHCP.  It could 
> *even* be used 
> in conjunction with mobile-ip, and not just for the FA.  
> Thus, one uses 
> one mechanism for mobility, another one for a stable 
> identifier, and for 
> that matter, perhaps a third for micromobility.  This falls under the 
> classification of "the right tool for the right job".

Readdressing the nodes is not the problem. In IPv6 the RA allows a
smoother version of doing that job, because it allows both old and new.
The real problem is in finding all the places that addresses are
explicitly stored.

> ...
>    user@pobox.com (for example) uses pobox.com as a place to have a 
> stable identifier.  This would be no different than 
> user@userspersonaldomain.com except that it takes some amount 
> of work to 
> maintain a server.  

The server is not the problem. This is due to the difference between a
central vs. distributed database. The user can change user@pobox.com and
it happens as quickly and as often as the user wants to change it. With
a personal domain, the minimum usable time is measured in hours, and to
be completely useful, we are talking a day or two (I have first hand
experience here because Verizon changes my address a couple of times a
year, and it takes a few hours after I get the dns updated before I can
use the name). 

> But even so the name remains the same.  So long as 
> userspersonaldomain.com can easily determine its address, and records 
> can be updated by authorized individuals, life continues. 

Eventually ...

> This is 
> possible.  Ralph Droms has worked on functionality such as prefix 
> delegation.  Then, see above.
> 
> Can you explain to me why systems that use translation other than DNS 
> aren't broken and worth fixing?

Because it is DNS that is broken (read that not reliable and fast) and
hasn't been fixed in 15 years. When people either can't register values
in DNS (due to lack of a scalable trust infrastructure for access to the
database), or their app can't reliably get answers back in the necessary
timeframe, they choose to build their own explicit tables. One simple
version of this is router acl's, another is SIP or multi-player game
rendezvous points. DNS does not work for all applications, therefore DNS
names can't be the solution for all multi-homing.