Subject: FW: Goals vs. process

From: "Tony Hain" <[email-masked]>
Date: Mon, 7 Apr 2003 17:47:38 -0700

It appears I didn't reply to this in a way that went to the list.

> -----Original Message-----
> From: Tony Hain [mailto:[email-masked]] 
> Sent: Monday, April 07, 2003 9:53 AM
> To: 'Margaret Wasserman'
> Subject: RE: Goals vs. process
> 
> 
> Margaret Wasserman wrote:
> > You believe that they are a valuable tool for network
> > administrators today -- as local, PI addressing.
> 
> And that PI takes priority over global routability. This is 
> evidenced by NAT of unroutable global IPv4 as a preference 
> over PA space. 
> 
> > 
> > I think where I stand is pretty clear...
> > 
> > I wrote a 30+ page document that outlines the problems and
> > benefits with site-local addressing and concludes that the 
> > problems far outweigh the benefits.
> 
> That is impossible to conclude without understanding the requirements.
> 
> > 
> > I proposed the "limited" model to constrain site-local
> > addresses to completely disconnected networks.
> > 
> > I do think that the following needs are "real":
> > 
> >          1 Addressing for disconnected sites.
> >          2 Addressing for intermittently connected sites.
> >          3 The need for local access control.
> >          4 The need for provider-independent local addresses that
> >                  remain stable when providers change/renumber.
> > 
> > I just don't think that site-local addressing (ambiguous
> > scoped addressing, as defined in the scoped addressing 
> > architecture and as allocated in prefix FEC0::/10) is the 
> > right solution to any of these problems.  It is known to have 
> > substantial problems, and I think that we should stop 
> > encouraging people to invest in it further (in 
> > specifications, implementations, etc.)
> 
> As you note ambiguous space is not required for these, and a 
> globally routable PI would solve these. The routing commuity 
> refuses to accept any globally routable PI proposals, and 
> continually raises concerns that any non-routable space will 
> be leaked into the routing system.  
> 
> > ...
> > The addressing for #2 may be handled the same way as #1, but
> > actually making connections survive disconnection and 
> > re-connection at a new global address is more complicated 
> > than that, as it requires that all local 
> > connections/applications prefer site-local addresses while 
> > global connections/applications use global addresses.  We 
> > will need to figure out if this can be done in a way that is 
> > completely compatible with behaving optimally on stably 
> > connected networks, or if it will be necessary for 
> > implementations to get some type of configuration hint 
> > regarding which way they should behave. 
> 
> 'Optimal' behavior is a local decision, so hints are appropriate. 
> 
> > Or, possibly, we
> > need to consider a different solution for this case.  I agree 
> > that we need to understand what the actual requirements are 
> > here, before we can evaluate solutions.
> > 
> > We already have a couple of drafts that address #3 without
> > site- local addresses.
> > 
> > #4 is only really solved by stable, unique,
> > globally-routable, provider-independent addresses, but it 
> > could be partially solved by any solution to #1 (just like 
> > SLs partially solve it).  Let me explain why it isn't solved 
> > by just giving two addresses to every machine...  Assume I 
> > have a 200  node network with 10 routers.
> > 
> >          - If I use only global PA addresses, when my provider
> >                  changes, I will need to change the global
> >                  prefixes on my 30 routers, update my DNS,
> >                  update any access lists/security associations
> >                  on my 200 hosts (perhaps automatically), etc.
> >                  I will need to do this before any global
> >                  access will work.  In the meantime, local
> >                  access would continue to work until my formerly
> >                  PA addresses become invalid (not just un-preferred,
> >                  invalid), then it will start to fail if I haven't
> >                  renumbered yet.
> > 
> >          - If I use both global PA addresses and local prefixes,
> >                  when my provider changes, I will need to change
> >                  the global prefixes on my 30 routers, update
> >                  my (split) DNS, update any access list/security
> >                  associates related to global addresses on my 200
> >                  hosts (perhaps automatically), etc.  I will need
> >                  to do this before any global access will work,
> >                  although local access that actually uses site-local
> >                  addresses (if I have any applications that know
> >                  that they want to use site-local addresses) will
> >                  continue to work indefinitely, and any local access
> >                  that uses global prefixes will work until my
> >                  old PA prefix becomes invalid, as above.
> > 
> > Compare both of the cases above to what I do if I have NAT:
> > 
> >          - If I use NAT with internal local addressing and external
> >                  PA addressing, when my provider changes, I
> >                  renumber one side of my NAT box. Period.
> > 
> > So, it is my opinion that if people put the level of value on
> > provider-independence that you suggest (and I believe you), 
> > then they will choose NAT (and probably IPv4) unless/until we 
> > figure out a way to provide NAT-less, provider-independent 
> > global addressing in IPv6.  [Note:  I did not say that SL == 
> > NAT, nor did I say that SLs increase the value of NAT, etc.  
> > I think that we have this problem with or without site-local 
> > addresses.]
> 
> I read this as you agree that solving the fundamental 
> requirement for stable addresses will result in the need for 
> globally routable PI's. Also that if we only provide 
> unroutable-PI, people might still prefer NAT for operational 
> simplicity. If I read that right, I agree. 
> 
> > 
> > I know that we don't know how to solve that problem right
> > now.  But, could we please stop arguing about site-local 
> > addresses (which _don't_ solve that problem at all, and don't 
> > solve any problem well) and start working on solutions to the 
> > real problem?
> 
> The problem that ambiguity solves is enforcement of 
> unroutability of one form of PI space. It does that so well 
> that it creates issues for mergers or other non-public 
> interconnections. 
> 
> I agree we should get on with identifying the problems to be 
> solved, then solving them. My disagreement is over doing 
> anything that removes use of the current mechanism prior to 
> that work being completed. Partially that is due to a doubt 
> that even a simple majority of the ~130 voters for 
> deprecation will actually participate in solving the 
> problems, and partially that is due to a perception that the 
> group as a whole will not agree that the full set of 
> requirements are important enough to be included in the list. 
> If the result of the deprecation vote only results in a 'stop 
> work' directive on ambiguous addresses, I can live with that. 
> If it tries to go any further at this time, I am pointing out 
> that creates a serious problem because the site network 
> manager has no other tool for address space independent of 
> the provider.
> 
> In discussions with Bill Woodcock a few minutes ago, it 
> became clear to me we are really struggling over the 
> requirement of the ISP to have stable addressing as customers 
> switch providers, vs. the requirement of the edge site to 
> have stable addressing as the site switches providers; the 
> requirement of the routing community for a strong aggregation 
> model vs. the requirement of the edge site for address space 
> that does not lock them to a provider; and the requirement of 
> the application community for a single scope address space 
> vs. the requirement of the edge site to filter parts of the 
> space to a local scope of use. This looks like the community 
> against the requirements of the site network manager (also my 
> take on the SF meeting), which completely misses the point 
> that the site manager is the customer of these services. The 
> customer is the one spending the money, so their requirements 
> will win, one way or another.
> 
> Tony
> 
> 
> 

--------------------------------------------------------------------
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 [email-masked]
--------------------------------------------------------------------