Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 08:28:15 -0400

As all know I wanted these dreaded site-locals gone since we invented them in IPv6.
This has been discussed before if we can revisit this again that is a very good thing.
Steve and Randy are 100% correct.

I would also add they break lots of stuff.

/jim

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Thursday, June 06, 2002 2:46 PM
> To: Steven M. Bellovin
> Cc: [email-masked]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols
> 
> 
> Steve:
> 
> Having implemented SCTP and IPv6 together I could not agree with you
> more.
> I know in our work on scoping of addresses it got very very tricky on 
> attempting to figure out which set of addresses to tell the other
> SCTP endpoint about to avoid black hole conditions. So in the end
> the only way you could handle it is if the destination address
> of your INIT packet (consider it a SYN) was TO a site-local then 
> you could include your site-locals... This means that if the user
> sent the INIT to the global address then the peer NEVER gets informed
> of site locals.... maybe something not desired but unavoidable...
> 
> 
> Now with the new addition of site-scoping even this will break since
> one must all of a sudden be cognizant of what site the peer is on and
> only send a sub-set of the site-local addresses (gak!!). 
> 
> In all of this I have tried to figure out what use these site locals
> are?
> 
> If I have a global address why would I ever want to use a site-local? 
> If no global-addresses are available and I am not attached to the
> public inter-net I could possibly see using a site-local.. maybe but
> I would think this is more the 'dentists' office scenario where in 
> link-local will suffice... If the 'dentist' wants to talk to the
> insurance company I doubt that it would be in the 'dentist's' site...
> so he would need a connection to the global address space... and the
> problem goes away....
> 
> Only in a large company would I see a site-local being applied.. but 
> in such a company why not just use a global address? What does it
> buy me to have this extra address? I already know my assigned address
> space... I can have my company border routers prevent spoofing of
> my address into my network... so I can use the source being the
> global address that is assigned to me to "know" that I am in the
> same company...if thats what I want...
> 
> I may be able to see (maybe) that a large company wants to NOT
> connect to the global address space... so here site-local MIGHT be
> something I could use... but adding in scoped site-locals I just can't
> see a use for... It just causes all sorts of fun problems.
> 
> I would much rather see the company that is NOT going to want to
> connect to the global address space just have a way to get some
> global address space.... I realize with the current number scheme
> this is not possible so maybe a site-local does make sense in
> this one strange instance... but in this case the company 
> does not need
> to worry about global mixed with site-local :> 
> 
> So maybe site-local (if allowed) should only be valid if NO global
> address is defined :>
> 
> R
> 
> "Steven M. Bellovin" wrote:
> > 
> > In message 
> <[email-masked]>, Margaret Wasserm
> > an writes:
> > >
> > >I sent the attached message to the routing area discussion 
> list.  I thought th
> > >at people on
> > >the IPv6 list might be interested in this discussion, so I 
> will forward a mess
> > >age containing
> > >the responses after this one.  I suppose I just should 
> have cc:ed the IPv6 gro
> > >up in the
> > >first place...
> > >
> > 
> > My strong preference would be to drop site-local addresses 
> completely.
> > I think they're an administrative and technical nightmare.
> > 
> > Margaret has pointed out that our routing protocols don't support
> > site-local addresses.  The only alternative suggestion I've 
> seen thus
> > far is to run multiple instances of, say, OSPF on all 
> routers within a
> > site.  But how are these distinguished from each other?  
> OSPF runs with
> > an IP protocol number, not a port number, so we can't have multiple
> > instances that way.  And RFC 2740's specification of the necessary
> > multicast addresses notes that they're all link-local.  
> Still, there's
> > apparently running code; I look forward to seeing the details.
> > 
> > I'm very concerned about DNS entries.  When should a DNS 
> server -- or a
> > caching resolver -- return a site-local address?  (If the DNS never
> > returns such things, they're useless.)  One suggestion I've heard is
> > two-faced DNS servers -- only return site-local information if the
> > querier is within the same site.  Apart from the fact that I have no
> > idea how that determination can be made -- surely no one 
> will suggest
> > putting site-local addresses into NS records -- RFC 2182 
> (aka BCP 0016)
> > specifically warns against putting all secondary servers for a zone
> > within a site:
> > 
> >    Consequently, placing all servers at the local site, 
> while easy to
> >    arrange, and easy to manage, is not a good policy.  
> Should a single
> >    link fail, or there be a site, or perhaps even building, or room,
> >    power failure, such a configuration can lead to all servers being
> >    disconnected from the Internet.
> > 
> >    Secondary servers must be placed at both topologically and
> >    geographically dispersed locations on the Internet, to 
> minimise the
> >    likelihood of a single failure disabling all of them.
> > 
> > Etc.
> > 
> > There will also be a lot of unnecessary pain in DNS maintenance as
> > "sites" are split or merged.  v6 is designed to support 
> easy renumbering
> > of global addresses, but those are designed to reflect topology.
> > Site-local addresses do not, which increases the probability of
> > address space collision during a merger.
> > 
> > Philosophically, I think that the problem is that a "site" is a new
> > (and deliberately poorly defined) concept.  The DNS is 
> designed to work
> > with administrative boundaries, while routing and addressing reflect
> > topology.  We now have a new concept that is neither 
> administrative nor
> > topological, but one that must be supported by administrative and
> > topological mechanisms.
> > 
> > Finally -- and perhaps least important -- I'm not sure what problem
> > they solve.  I can understand site-local multicast, since (most)
> > inter-site traffic traverses links that are not inherently
> > multicast-capable.  There is thus considerable extra 
> expense.  But why
> > do I need site-local unicast addresses?
> > 
> >                 --Steve Bellovin, 
> http://www.research.att.com/~smb (me)
> >                 http://www.wilyhacker.com ("Firewalls" book)
> > 
> > --------------------------------------------------------------------
> > 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]
> > --------------------------------------------------------------------
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

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

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 13 Jun 2002 17:17:04 -0700

It is time to get off this thread and back to real work. Those who want
SL removed should get 1918 moved to historic first, get all products
using that off the market, then come back and raise the issue. Since we
know that won't happen, the constructive thing to do is for those that
don't think they can support SL to leave it out of their implementation,
while those that have figured out how to use it as a differentiator can
leave it in. Yes that might cause interoperability problems, but only in
the case where a site was running with SL as its only prefix. When a
node doesn't support SL, it will be hard pressed to register an SL
address in whatever name resolution system is being used, and if a
product can't respond correctly to an SL address, an administrator
shouldn't register it. Every node should be able to work when only a
global address is returned, so in any realistic scenario, where is the
interoperability problem?

On the topic of documenting when and how SL interacts with DNS or SIP or
your favorite name-to-address-mapper, yes more work is needed. I would
argue this belongs in the DNS WGs, but if their approach is to ignore it
because it is different from current operation, then the IPv6 community
will have to corner some DNS experts long enough to learn the issues. In
any case it doesn't make sense to waste time arguing that 'XYZ
configuration will not work', when no sane network manager would
configure a network that way. When particular configurations don't work,
pointing that out in documentation makes sense, but demanding to throw
out the mechanism because an obscure corner case fails is not good
engineering.

One issue that I am surprised has not been raised here is the case where
a node has administrative restrictions on which prefixes it can learn
from an RA (specifically so that it will only work on the home network),
and that list includes SL. If that node appeared on a foreign net, it
would ignore the globals, but would happly accept any SL and may be wide
open. One could argue that it shouldn't happen, but consider the case
where enterprise-A uses 802.11, and a laptop with it built-in (and no
administrative rights to the user to turn it off) were to show up at
enterprise-B. The sys-admin may have thought the machine was reasonably
protected by the filter list on the RA, but by using SL left that node
wide open when it was away from home. This is not an argument that SL
shoudl be dropped, just that it is not appropriate in all contexts.

One case where it does make sense is in consumer electronics that are
intended for local in-home use, and have no reason for global
addressibility (say a light switch). Those who want SL removed are
arguing that the average consumer will be required to manage a firewall
to keep the global address of the light switch from being reached
externally. Many of them can't even get self-configuring NATs to work
with help from a support desk, so forget any hope that they will do
something more complex. While having the light switch accessed by a
control unit could be done with LL, does it make sense to have a control
unit connect to every possible link technology in a home, or does it
make more sense to use SL from a stand-alone control unit and have a
routing device attach to the different segments? We typically define
control and routing jobs as separate functions, so why would someone
expect that they now magically show up in the same box? The router
should be a cheap box with nothing but connectors, while the control
unit has a fancy UI and may be replicated in multiple locations.

As I scan through this thread, it started by questioning the lack of
documentation about how SL should work in a particular context, but
quickly degraded into an attack on change. The IETF is about managing
the consistent change that has been taking place in networking, so
standing up and saying 'take this out because it requires us to change
the way we have done it forever' is counter to our role. Documenting
that a mechanims works in configuration A, not at all in configuration
B, and we haven't figured out configuraion C, is what we need to do
here, so lets get on with it.

Tony

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Jun 2002 17:23:34 -0700

> SL removed should get 1918 moved to historic first

complete red herring.

a socially better case of this herring would be to cure world hunger first.

we may not like 1918, but that does not mean we should reproduce it to show
our dislike.

randy

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 13 Jun 2002 17:50:31 -0700

> > SL removed should get 1918 moved to historic first

They are designed to serve the same purposes. Clearly the market has
found several uses for 1918, so claiming any of those (except expanding
the address space by reuse) are void in an IPv6 world is a bit academic.

> we may not like 1918, but that does not mean we should

There are uses for 1918, and life would have been good without NAT. We
need to keep the real problem child in focus and not blame 1918 for the
transgressions of NAT.

Service providers and network managers clearly know the boundaries of
their routing complex, and may find that using SL is a reasonable
mechanism for SNMP and other management traffic, much as they use 1918
now. The issues raised on the thread have mostly focused on cases where
the site boundary is not clear. When there is no clear boundary then SL
shouldn't be used, just as you can't use 1918 in those cases now.

Tony