Re: A new spin on multihoming: multihoming classes.

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Peter" == Peter Tattam <peter@jazz-1.trumpet.com.au> writes:
    Peter> The suggested IPv6 solution is to limit the choices that the DFZ routers need
    Peter> to make and push the MH decision making to the edges.  By doing so, you throw
    Peter> away the MH information visible at the core and you have to regain it another
    Peter> way (which I've said before).

  Let me reword this:
      push the MH decision away from the DFZ

  The thing about IX based solutions with geographically significant
addressing is that it pushes the problem down to the IX and municipal area
network. 

  My preferred solution is to use geographically significant addresses as the
PI address format, but to then use some kind of address exchange mechanism
inband (a la what you have described).

  I am not clear why this "inband" system is any different than MobileIP,
nor why it should be secure when MobileIP is not. My preference is therefore
to use either Binding Updates or a minor variation of them to do this. 

  Geographically significant addresses may never get optimal routing. 
  It may even be necessary to configure tunnels to geographical address
concentrators to get the first packet through. 

  (This is easily done with IKE and IPsec and scales rather well as the
relationship with the address concentrator must be pre-existing. I would
further suggest that it is entirely appropriate that these system be a
municipally governed service, but that is a local jurisdiction issue)

  If I wanted to put a web server up in this scenario, I'd give
www.example.com a geographically significant address in DNS. I'd could then
have references to the rest of the site be www-ispA.example.com or some such
with a PA address that leads to the appropriate place, or just depend upon
each host having some kind of PI->PA cache.

  [This can wreck havoc with long term bookmarks, but many of these web sites
are entirely generated anyway, and bookmarks fail here anyway. Putting a URL
in that is appropriate for "bookmark"ing is probably a todo for W3C anyway]

    Peter> Finally I might add that I have to concede there is one
    Peter> fundamental flaw in the 
    Peter> host based or DNS based solutions to MH and that was eloquently pointed out by
    Peter> someone else.  DNS needs routing so routing can't depend on DNS which means we
    Peter> can't use it as it is currently implemented, primarily because DNS is agnostic
    Peter> towards routing conditions.

  While I would agree that we would like to have the root, and TLD servers
multihomed (and in particular, we'd like to have a stable set of addresses to 
put into named.ca), DNS has some rather nice features for discovering the
entire list of addresses of nameservers already. The first thing that one
usually does when a DNS server starts is to ask the root servers for a list
of root servers. They could easily return all of their PA.

  So, while I would agree that having a *routing* system that depends upon
DNS is a deadlock, having a *multihoming* system that depends upon DNS may
not be a loss.
  I would prefer that we did not rely on DNS however.

    Peter> An idea springs to mind - why not have an alternative system based on BGP
    Peter> *independent* of the routing system from which reachability information can be
    Peter> gathered.  Such a BGP system would need to be extended so that whole DFZ would
    Peter> not need to be kept in the BGP server, but rather the localized routing needs
    Peter> of the site instead, much in the same way that a DNS server only keeps the
    Peter> localized name mapping that it requires for the sites current connections.

  Like a geographical IX system?

    Peter> If this has been thought of before I completely apologize to the original
    Peter> proposer.

  I think it is in one draft.
  Hmm. Now I don't know which one! We need a better list of drafts under
consideration.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface

iQCVAwUBO50clYqHRg3pndX9AQFCtwQA7phFAakYQ4KtkHq9M4dSgKN1kfRWU7Hr
iR7IJsRfATdAkUWqK1Xn+ArMd8wQjFa4R6txULRxs10ViY6Ii+OgWJ79W7Qs8phw
hka/oUSa/1zxh8XnLlzQjgikQ0UYh8PFQvgABt5MMdmrsr+kxu5Qp/qTs9dKe4lj
PazDX42/pYo=
=3P/x
-----END PGP SIGNATURE-----