renumbering/multi-addressing [Re: Enforcing unreachability of sitelocal addresses]

[Michael Thomas <mat@cisco.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Pekka, 

It seems to me that you left out the most
nettlesome problem about why people want address
stability: name mappings, both in the form of DNS
and everywhere else you find raw IP addresses
floating around. In many ways, this mimics the Y2K
problem in that it's very hard to gauge _what_
exactly might break until you do a complete
assessment. And the complete assessment is enough
to scare the timid woodland creatures away. 

Until there's a realistic way for people to pull
the lever and make a switch, there's going to be a
lot of back pressure to keep address stablity
regardless of how harmful their means of keeping
stablity is to the net at large.

	    Mike

Pekka Savola writes:
 > Hello,
 > 
 > I added multi6 on Cc: list for this particular piece of the thread.
 > 
 > On Sun, 26 Jan 2003, Margaret Wasserman wrote:
 > [...]
 > > Some folks have argued that easy renumbering would eliminate the need
 > > for enterprises to have provider-independent addressing, but I don't
 > > agree.  Addresses are stored in many places in the network besides
 > > the interfaces of routers and hosts, such as access control lists,
 > > configuration files, .hosts files, DNS configurations, ACL lists, etc.
 > > In many cases, addresses are stored in nodes on other subnets.  So,
 > > being able to renumber the interfaces of hosts and routers on a
 > > particular network or subnet doesn't even solve half of the problem.
 > 
 > There are multiple reasons why people want PI addresses.  Renumbering and
 > multi-addressing has multiple different models.  Some are easy and some
 > are very difficult.  We should develop at least the _easy_ solutions
 > because they are probably useful too.  For now, it's enough to manage the
 > first 80% of the problem.
 > 
 > Consider four reasons why people might want PI, routable addresses:
 > 
 > - "I don't want to be in problems if my ISP goes bankrupt!"
 > ==> multiple addresses are just fine here (deploy them before the ISP 
 > goes down, but use only one set of them etc.)
 > 
 > - "I want to be able to change ISP's at will reasonably easily, to keep an 
 > edge"
 > ==> multiple addresses are fine here too!
 > 
 > - "I want to be able to protect against failures in my link(s) to my ISP 
 > and problems in our router(s)"
 > ==> multiple addresses can deal with that too, with some added glue!
 > 
 > - "I want to be able to protect against failures in my upstream ISP"
 > ==> tough cookie, no solution here!
 > 
 > Get the picture?  Greedy folks want it all, but actually we _can_ provide
 > quite a bit of it already!
 >  
 > > Choices seem to be:
 > > 
 > >          (A) Continue with PA addressing, and accept that enterprises will
 > >                  use IPv6 NAT to get provider-independence.
 > >          (B) Allocate PI addresses, and trust that we can determine a
 > >                  scalable PI routing scheme before we hit route scaling
 > >                  issues in the IPv6 backbone.
 > 
 > I don't comment on these except that you seem to be making some 
 > conclusions I don't agree on.  I don't think PA equals IPv6 NAT, not at 
 > all.  There are solutions there.
 > 
 > -- 
 > Pekka Savola                 "You each name yourselves king, yet the
 > Netcore Oy                    kingdom bleeds."
 > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
 > 
 > 
 > --------------------------------------------------------------------
 > IETF IPng Working Group Mailing List
 > IPng Home Page:                      http://playground.sun.com/ipng
 > FTP archive:                      ftp://playground.sun.com/pub/ipng
 > Direct all administrative requests to majordomo@sunroof.eng.sun.com
 > --------------------------------------------------------------------