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

From: Keith Moore <[email-masked]>
Date: Thu, 06 Jun 2002 15:51:25 -0400

> My strong preference would be to drop site-local addresses completely.
> I think they're an administrative and technical nightmare.

for that matter, so are link-local addresses.  they do have some
legitimate uses, but they need to be kept to a minimum
(in both ipv6 and ipv4)

Keith
--------------------------------------------------------------------
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: Randall Stewart <[email-masked]>
Date: Thu, 06 Jun 2002 13:46:14 -0500

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...
> >
> 
> 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)
> 

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 06 Jun 2002 13:36:28 -0400

Etc.

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Jun 2002 11:24:57 -0700

> I think they're an administrative and technical nightmare.

trying to solve a routing problem by an ill-understood addressing
hack.

randy

---

From: [email-masked] (R.P. Aditya)
Date: 06 Jun 2002 13:27:47 -0700

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    >> My strong preference would be to drop site-local addresses
    >> completely.  I think they're an administrative and technical
    >> nightmare.

    Keith> for that matter, so are link-local addresses.  they do have
    Keith> some legitimate uses, but they need to be kept to a minimum
    Keith> (in both ipv6 and ipv4)

The problem with site-local addresses is that the "site" scope is
ill-defined. For link-local addresses, as long as the scope is
well-defined, what are your objections?

thanks,
Adi

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Jun 2002 12:22:59 -0400

> For link-local addresses, as long as the scope is

for the most part, they're only a problem if you try to use
them in applications (where zero-configuration appliances
are an important subset of applications)

part of the problem is that the scope of link-local addresses
is *not* well-defined from an application's point of view,
since applications in general don't know, and shouldn't have
to know, about network topology.

(scoped addresses in general are a nightmare for apps)

so LL is fine for RD/ND etc.  but the vast majority of apps
should never see them.

unfortunately the zeroconf WG is trying to make LL addresses
be a general-purpose mechanism for internet appliances to
obtain an address - perhaps without supporting any mechanism
to get a global address,  assuming (incorrectly IMHO) that the
hosts that need to access that appliance will be on the same
link anyway.

the problem is not the fact that LL addresses exist, it's that
there are no well-defined constraints on their use.

Keith

---

From: [email-masked]
Date: Sat, 08 Jun 2002 02:09:33 +0900

>to know, about network topology.

	as long as the applications are properly implemented with sockaddrs,
	they are okay.  the problem reside in protocols that pass IPv6
	addresses in payloads (since view of the scope is different by nodes),
	including:
	- FTP (EPSV/EPRT does not help - for instance, how do you decide
	  the scope zone for data connection?)
	- DNS (AAAA/PTR does not represent scope correctly)
	- and all NAT-unfriendly protocols

	I'm okay to see site-local IPv6 address to go away, however, I'm
	worried because there are more than a couple of protocols designed with
	site-local IPv6 address in mind (DHCPv6, router renumbering, ...).

	we need to keep link-local IPv6 address at least for ND.  use of 
	link-locals within zeroconf environment needs further study.

itojun

---

From: Ralph Droms <[email-masked]>
Date: Fri, 7 Jun 2002 13:15:22 -0400 (EDT)

DHCPv6 currently uses a site-scoped multicast address as the default for
forwarding messages from a relay agent to servers.  The relay agent can be
configured with a list of unicast addresses for servers instead of using
the site-scoped multicast address.

DHCPv6 also depends on link-local addresses for communication between the
client and the on-link relay agent.

- Ralph

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Jun 2002 13:17:12 -0400

>         they are okay.  

sockaddrs do not solve the problem of applications having to figure out how
to reach a peer application in the absence of any knowledge about network
topology.  the source-selection rule isn't sufficient either.

> the problem reside in protocols that pass IPv6

it's entirely appropriate for applications to pass addresses in payloads,
and it's essential functionality for many kinds of applications
(distributed apps in particluar).

for better or worse, the internet does not have a location-independent namespace
that is reliable and useful for doing referrals to peer processes.  and nobody
has demonstrated an effective way to retrofit one into the current architecture.

>         link-locals within zeroconf environment needs further study.

we agree about that much.  but they think they're ready for standards-track.

Keith

---

From: [email-masked]
Date: Sat, 08 Jun 2002 02:21:34 +0900

>	addresses in payloads (since view of the scope is different by nodes),

	i'm not saying that these protocols are bad.
	s/problem reside in/site-local address does not play nicely with/

itojun

---

From: Bob Hinden <[email-masked]>
Date: Fri, 07 Jun 2002 15:56:42 -0700

Steve,

Thanks for raising this issue on the list.  I think it has been lurking for 
a while.

(with no hat on)

Here is my personal explanation about why site-local addresses exist.  My 
intent of the email is to not take a strong position on either side.

>do I need site-local unicast addresses?

It may be the most important question, not the least important :-)

One of the original reasons for site-local unicast addresses was for sites 
that were not connected to the Internet (and didn't have any global 
addresses).  They would allow IPv6 be used inside the site 
initially.  Later when the site become connected to the Internet it would 
be easy to renumber to a global prefix because the subnet part of the 
addresses (/48 in current assignment practice) could be reused without any 
site subnet renumbering.  This usage of site-local unicast may still have 
some value and avoids some of the complexity of using a mixture of global 
and site-local addresses.

Later as many people came to belive that private addresses (and NAT) in 
IPv4 provide a security mechanism, Site-local addresses were looked on as 
filling that role in IPv6.  I understand that the belief that private 
addresses provide security is faulty and has many nasty consequences, but 
many people do believe it.  I think this has evolved to where there is a 
view that using site-local unicast addresses for services that need to be 
restricted to the site is a good thing.  I think there is some value here, 
but am not sure if it's benefits justify it's costs.  I think there are a 
range of opinions here.

All of the issues you point out about site-local regarding DNS and routers 
are real.  However with the widespread use of IPv4 private addresses in the 
internet, that vendors have leaned how to deal with addressing domain 
issues.  I don't think the IETF has done very much to "standardize" this 
usage (probably a good thing).  I think most vendors building these 
products know how to deal with the issues and users have learned how to 
configure the products to solve their problem.  The vendors built it 
because their customers wanted it.  It is all very ugly and nasty.  It is 
hard to set up and even harder to debug problems.  Perhaps even as you say 
"an administrative and technical nightmare".  But as far as I can tell it 
does exist.  If vendors are going to build products that want to use 
site-local, then it might be best for the IETF to at least document it's 
usage to allow for interoperability.

(with my IPv6 co-chair hat on)

I think the w.g. has some choices to make regarding site-local addresses.

1) Remove site-local from the IPv6.

This would involve remove it from the IPv6 addressing documents and find 
all other documents that mention them and update these.  Some of these may 
require significant modification if use site-local as a basic part of their 
mechanisms.  There will also be an impact to shipping IPv6 
implementations.  This would have to be sorted out.  A good understanding 
of what different vendors plan here would be useful.

2) Keep site-local but limit it's scope of usage.

This would be something like writing an applicability document that defines 
it usage and for example restricts it use to sites not connected to the 
Internet.  Other usage would be for future study.  This would be consistent 
with most of the current specifications.  It would make completing the 
scoped address architecture document simpler.  There might be other 
specifications to update if they were using site-local and didn't have any 
provision to move to global addresses.

3) Keep site-local and allow full usage

This would mean fully specifying how to use site-local, documenting the 
router and DNS issues, completing the scoped addressing architecture 
document, perhaps enhancing IPv6 routing protocols to have more knowledge 
of site-local addresses, etc.

The working group has been going down 3) for some time now.  I think your 
email is a good start at seeing if should continue in this direction or 
change course.

Bob

---

From: Francis Dupont <[email-masked]>
Date: Mon, 10 Jun 2002 11:45:26 +0200

In your previous mail you wrote:

=> many of us share your opinion but the other side has enough people
to make a consensus unlikely...

   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?

=> using the fact an interface belongs only to one site.
OSPFv3 has an explicite provision for multi-instance per router
(the idea was to make OSPF available on DMZs) so someone can shoot in
his foot (oops, can run multiple OSPF processes on a multi-sited router).

   querier is within the same site.

=> yes, the basic answer is the two-headed devil...

   RFC 2182 (aka BCP 0016) specifically warns against putting all
   secondary servers for a zone within a site:
   
=> this obviously doesn't apply in this way for scoped names/addresses.

   Philosophically, I think that the problem is that a "site" is a new 
   (and deliberately poorly defined) concept.

=> I propose to reserve the "what is a site?" question to Steve Deering (:-).

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 10 Jun 2002 11:55:20 +0200

=> add IKE in this list (with an additional security issue too).

=> as I proved in a not-yet published draft, for some protocols to be
NAT-friendly introduce a nasty vulnerability...

=> this is a design error and the last meeting discussion about where are
the site boundaries for a dialup connection showed where is the problem.

=> I am not against scoped addresses in zeroconf environment where they
use only one zone, i.e. link-locals with only one link, or site-locals
with only one (disconnected) site...

Thanks

---

From: Alain Durand <[email-masked]>
Date: Mon, 10 Jun 2002 15:08:50 -0700

On Friday, June 7, 2002, at 03:56 PM, Bob Hinden wrote:
> This would involve remove it from the IPv6 addressing documents and 
> find all other documents that mention them and update these.  Some of 
> these may require significant modification if use site-local as a basic 
> part of their mechanisms.  There will also be an impact to shipping 
> IPv6 implementations.  This would have to be sorted out.  A good 
> understanding of what different vendors plan here would be useful.
>
> This would be something like writing an applicability document that 
> defines it usage and for example restricts it use to sites not 
> connected to the Internet.  Other usage would be for future study.  
> This would be consistent with most of the current specifications.  It 
> would make completing the scoped address architecture document 
> simpler.  There might be other specifications to update if they were 
> using site-local and didn't have any provision to move to global 
> addresses.

A potential drawback is that the day those sites connect to the 
Internet, they will have to renumber.
Until the renumbering story is significantly better, there will be 
temptations to use IPv6 NAT...

> document, perhaps enhancing IPv6 routing protocols to have more 
> knowledge of site-local addresses, etc.
>
> The working group has been going down 3) for some time now.  I think 
> your email is a good start at seeing if should continue in this 
> direction or change course.

This path is expensive, as seen in the current thread.

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Mon, 10 Jun 2002 15:08:50 -0700

- Alain.

---

From: Ignatios Souvatzis <[email-masked]>
Date: Mon, 17 Jun 2002 14:43:19 +0200

> I think they're an administrative and technical nightmare.

What will people use instead of site-local addresses to build auto-configuration 
of structured networks? I'm thinking of approaches like

IPv6 Stateless Address Autoconfiguration for Hierarchical Mobile Ad Hoc Networks
		<draft-weniger-manet-addressautoconf-ipv6-00.txt>

When you're done detecting internal structure, and assigning internal addresses, just
advertise a global prefix and get external connectivity, just like link-local addresses
are used for flat network auto-configuration, and router advertizements are used
later to add a prefix that is externally routed.

Without site-locals you'd need to use a global address prefix to do so - but need the
network first to learn of it.

Regards,
	-is