Subject: RE: Proposal for site-local clean-up

From: "Brian Zill" <[email-masked]>
Date: Wed, 13 Nov 2002 04:39:28 -0800

Keith Moore writes:
> Hesham writes:
> > - "MUST NOTs" are there for a reason, saying MUST NOT
> > when it can be done and protocols don't break is not
> > a good idea.

I agree with Hesham.  We shouldn't be applying "MUST NOT"s to situations
where we have workable solutions.  Restricting site-locals to isolated
networks is not a good idea.

> > - People have shown that there are ways of using
> > site-locals for single and multi-sited hosts today and
> > making sure that apps don't break.
> 
> actually, no.  people have shown that there are ways of
> using SLs for some apps in such situations.  nobody has
> come up with a general solution that requires less than
> either:
> - expecting all non-isolated networks to provide global
>   addresses (and having apps ignore SLs in the presence
>   of globals), or 
> - expecting apps to do their own addressing and routing.

Which is just fine!  Nobody was arguing that non-isolated networks
shouldn't provide global addresses -- they should.  If someone want to
talk globally, they should use global addresses.  I think we could get
consensus on that.  (I'd make a small argument about your "ignore SLs in
the presence of globals", however, since I already showed how using
site-locals can work if the site-local is never passed outside of its
scope zone).

I claim that requiring non-isolated networks to provide global addresses
to those entities which desire global connectivity *is* a general
solution (and certainly a much better solution than banning site-locals
on non-isolated networks).  So why don't we standardize on that?

--Brian

P.S.  A couple other posts in the last few hours have shown that people
are (finally!) starting to think through the misguided proposal to ban
site-locals and realizing the downsides.  I'd like to add one more: how
are sporadically connected sites (e.g. a small home/office net with a
pay-by-the-minute dialup link that gets a different prefix each time it
connects) supposed to work if site-locals are banned from connected
networks?  Person X isn't going to want their intrasite connection to go
down because person Y wanted to check their mail on the Internet.  We
have a workable solution for this today in site-locals.  Do we really
want to encourage such sites to use link-locals and multi-link subnet
routers between all their links?

--------------------------------------------------------------------
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: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 13 Nov 2002 14:37:47 +0100

> on non-isolated networks).  So why don't we standardize on that?

my reading is that "banning" site-locals from connected networks is going 
to be a simplification mechanism for standardization, not a requirement for 
configuration of live networks....

every time we come across a case where complexity is increased by 
considering how to use site-local concurrently with global addresses (my 
favourite list starts with source address selection and DNS lookup, but 
does not end there.....), we can safely say "but we don't have to solve 
that - it's not supposed to be that way", and move on with a simple 
solution that works for the global case.

If people come up with things that work with site-local under those 
conditions, they will no doubt use them - but they should not expect to get 
any help from other parts of the infrastructure in sorting them out.

The IETF has *never* had an enforcement arm.

                    Harald

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Nov 2002 08:56:44 -0500

> where we have workable solutions.

the closest thing we have to a workable solution is to find a way to
give every site that connects to another network a global prefix 
(whether it's globally connected or not) and have applications 
ignore the SLs (at least for purpose of referrals).  and if you do 
that, there is little point in having SLs at all except for
isolated networks - they just complicate management and DNS etc.
for the networks that use them.

> talk globally, they should use global addresses.  

but this isn't just about sites that want to talk globally - this
is about sites that connect to other sites, some of which talk 
globally.   and again, if any of those sites use SL, then apps
that communicate across site boundaries are forced to implement
their own addressing and routing.

> (I'd make a small argument about your "ignore SLs in

yes, but that presumes either that all such sites have global addresses
or that there is never a need for an extra-site party to perform a
referral between two hosts on the same site.  neither seems reasonable.

> solution 

I disagree.  network A isn't necessarily providing global connectivity 
(transit) to network B even though A as global connectivity and
A and B connect to one another.  

the problem is that applications that communicate between A and B
and perhaps with nodes on other networks need a linear address
space, and they don't have one if any of those networks use site-locals.

also, insisting that A give up a part of its address space to B
just in order to connect to B can be problematic - it affects A's
existing organization of its address space.  (just because so much
address space is available does not mean it will be well-utilized!)
my guess is that enterprise networks will be reluctant to give up
part of their address space to allow other enterprises to connect.
and if B wants to connect to several networks, which one gives up 
part of its address space?

Keith

---

From: Markku Savela <[email-masked]>
Date: Wed, 13 Nov 2002 16:38:55 +0200

> From: Harald Tveit Alvestrand <[email-masked]>

> does not end there.....), 

1. There is NO PROBLEM with source address selection. 

 - if your destination is site local, your source address is
   site-local,

 - if your destination is global, your source is global,

If there are any changes in source address selection, I would
actually wish that it is always required that source source and
destination are always same scope. (Now it is apparently allowed to
use higher scope source address).

Because IPv6 has link local addresses, the source address selection
machinery with scopes must be done anyway, and supporting site locals
does not bring in any extra complexities.

2. I accept that DNS-issue needs some discussion and defintion.

My view on this is that you need the "scoped DNS" architecture, which
can be seens as extension to "two-faced DNS". You can have
  
 a. global DNS service (the current)
 b. site local DNS service
 c. link local DNS service

and you have the normal search order policy inside your resolver, for
example

   1. look hosts file
   2. look global dns service
   3. look site local service
   4. look link local service (LLMNR)

the proces stops when answer is found from any level (e.g. if global
service gives positive answer, site and link local are not
queried). "Not found" answer is trickier: continue to next level or
not? (probably needs to be somewhat configurable).

Not all levels need to be present always.

---

Stacks have already been implemented and delivered with support for
site locals. The support stays in, and it's up to users and site
admins to decide whether they are used or not.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 13 Nov 2002 15:57:48 +0100

--On onsdag, november 13, 2002 16:38:55 +0200 Markku Savela 
<[email-masked]> wrote:

> (my

sorry, I misspoke.

the problems I have heard people yelling about are endemic to having 
multiple addresses of different scopes available, and "source address 
selection" is just one aspect of picking the "right" source/destination 
pair.

                  Harald

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Nov 2002 10:46:55 -0500

> can be seens as extension to "two-faced DNS". You can have

DNS is only one of many applications that have this problem.  you can't
solve the DNS problem and ignore those of the other applications.
also, scoped DNS will break applications that expect a consistent view
of DNS from one site to another, and it will break DNS caching.

so for me, standardizing scoped DNS is out of the question.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 13 Nov 2002 08:41:53 -0800

Keith Moore wrote:
> the closest thing we have to a workable solution is to find a 
> way to give every site that connects to another network a 
> global prefix 
> isolated networks - they just complicate management and DNS 
> etc. for the networks that use them.

It doesn't matter how many times you write this, you can not make it
become true. Brian keeps pointing out the simple case of an
intermittently connected network getting a different prefix on each
connect, but you keep ignoring it. STABLE ADDRESS SPACE IS A MAJOR
APPLICATION REASON TO HAVE SL. 

Also, as I have said multiple times, getting rid of SL does not create
PI space. When PI space is available, people will most likely recognize
that it is easier to deal with than SL, and will naturally migrate. Even
when it is available, that does not automatically create a reason to
restrict the use of SL. It will always be easier to filter a short /10
than to maintain a long list of access controls at the border. THIS IS A
MAJOR OPERATIONAL REASON TO USE SL.

It is appropriate that we have a document describing the impact on
multi-party apps using literal referrals, and another on guidance on DNS
configurations. We have discussed the first many times, and the second
is nothing more than formalizing what people have been already doing in
the face of 1918 space. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Nov 2002 13:31:21 -0500

> APPLICATION REASON TO HAVE SL.

I don't disagree that currently the best solution for intermittently
connected networks is SLs.  That still doesn't make them work well
with applications.

(and no I haven't ignored this, actually I've explicitly cited this
as a valid use case for SLs)
 
> that it is easier to deal with than SL, and will naturally migrate. 

We agree that PI space is needed.

> Even

NO IT IS NOT.  First, you're not comparing the same cases here - you're 
assuming in one case that a filter will block off an entire network, and in 
another case you're assuming that  the site will need and use a long list of
access controls.  What you seem to be arguing is that sites don't need the
flexibility to block or permit external traffic to individual hosts, 
nor do they need the flexibility to block or permit traffic within their
internal networks.  I don't buy it.
 
> is nothing more than formalizing what people have been already doing in

Formalizing that practice is exactly the wrong thing to do - it degrades 
the value of DNS for use by applications.  

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 13 Nov 2002 11:36:10 -0800

Keith Moore wrote:
> ...
> > than to maintain a long list of access controls at the 
> border. THIS IS 
> > A MAJOR OPERATIONAL REASON TO USE SL.
> 
> another case you're assuming that  the site will need and use 
> a long list of access controls.  What you seem to be arguing 
> is that sites don't need the flexibility to block or permit 
> external traffic to individual hosts, 
> nor do they need the flexibility to block or permit traffic 
> within their internal networks.  I don't buy it.

I don't know how you can get from needing a simple filter to not needing
a filter...
A simple example would be; as per spec, SL is blocked at the border,
globals are allowed without restriction, and hosts that are allowed out
have a policy that allows them to configure a global prefix along with
the SL one, while those that are not allowed out have a policy that only
allows configuring an SL prefix. Address selection says use the smallest
scope, so internal communications use SL and are forced to stay internal
by the hard filter at the border. This puts the burden of policy
application at the address assignment time (very infrequent) rather than
parsing every packet for access control.

> > multi-party apps using literal referrals, and another on 
> guidance on 
> > DNS configurations. We have discussed the first many times, and the 
> > second is nothing more than formalizing what people have 
> been already 
> > doing in the face of 1918 space.
> 

You are trying to legislate against current practice, rather than
documenting it so that app developers can understand the real
environment.

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Nov 2002 14:56:53 -0500

> parsing every packet for access control.

this is not workable for several reasons.  

first, it expects apps to work across site boundaries betwen hosts that 
use SLs.  that's simply unacceptable.

second, it's not secure without filtering. 

third, address selection is not a policy mechanism, it is a default 
behavior, that applications are free to ignore - and there are many 
cases where it's highly desirable that they do so.

fourth, the idea that address selection for internal communications
does not affect external communications is naive.

> documenting it so that app developers can understand the real

You are trying to force a practice that is known to be broken,
and the burden of trying to make apps work in the face of that
broken practice, on everyone.   There is no way that this can
be justified.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 13 Nov 2002 12:43:48 -0800

Keith Moore wrote:
> > I don't know how you can get from needing a simple filter to not 
> > needing a filter... A simple example would be; as per spec, SL is 
> > blocked at the border, globals are allowed without restriction, and 
> > hosts that are allowed out have a policy that allows them 
> to configure 
> > a global prefix along with the SL one, while those that are not 
> > allowed out have a policy that only allows configuring an 
> SL prefix. 
> > Address selection says use the smallest scope, so internal 
> > communications use SL and are forced to stay internal by the hard 
> > filter at the border. This puts the burden of policy application at 
> > the address assignment time (very infrequent) rather than parsing 
> > every packet for access control.
> 

One opinion. You keep saying that, but it is not requiring that the app
work using SL across the border. In fact the reason the network manager
likes SL is the apps will explicitly not work in that case. Are we
really talking about legislating against border filtering?

> second, it's not secure without filtering. 

Who said anything about security, and the point of SL is that there is a
well understood filter that gets applied between the public and private
network. Between private networks is a matter of local negotiation, but
that would be true in any case.

> cases where it's highly desirable that they do so.

If an app chooses to assert a policy that is different from the network
manager's filtering rules, it will fail. Having a well defined address
space that is known to have filtering applied allows apps to have a hint
about potential scope restrictions. That hint may or may not be helpful,
but lack of it leaves the app in complete trial & error mode.

> 
> fourth, the idea that address selection for internal 
> communications does not affect external communications is naive.

I can't parse this. The decision about internal / external
communications is a filtering decision. The address allocation /
selection mechanism for a well defined space makes that process
manageable, and reduces the burden on the filter process.

> You are trying to force a practice that is known to be 
> broken, and the burden of trying to make apps work in the face of that

I am not forcing anything. I am arguing that we maintain an
architectural principle, that allows current practice to be extended
away from the need for header mangling. You can't seem to see that the
option of having an address with limited scope does not require an app
to use it, while also insisting that apps that might want to run in a
limited scope are invalid. No one is requiring the apps you write to use
SL addresses.

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Nov 2002 16:21:36 -0500

> likes SL is the apps will explicitly not work in that case. 

Actually that's a delusion.  In today's networks the apps are still 
expected to "work" in that case; it's just that they require more 
complexity to do so, and they don't work as efficiently or as reliably.

> Are we really talking about legislating against border filtering?

No, we're talking about making border filtering useful.

> network. 

And if the purpose of this filter is not security (or the illusion thereof)
then what is it?

> manager's filtering rules, it will fail. 

Yes, though that doesn't mean that the network manager's policy was
realistic.  But a minute ago you were asserting that address selection 
prevented the need for such filters, now you're saying that the filters
will exist anyway.  Which is it? 

> Having a well defined address

No, it's just the opposite, at least if use of SLs is widespread.  
Apps will still be expected to operate across site boundaries,
and the fact that an SL address is used forces the app to use trial
and error to figure out which addresses work best for referrals.

> communications is a filtering decision. 

You were claiming that it's okay to use SLs for internal communications
and globals for external communications.  I'm saying that forcing apps
to use SLs for internal communications can prevent them from working
externally even if some of those nodes have globals.  The source address 
you use to talk to one node may get reused in a referral.  This is
standard practice today for many apps - it's one way to get around 
some of the problems imposed by NATs.  Don't expect those protocols'
paylods to change just to use IPv6.

> > You are trying to force a practice that is known to be=20
> away from the need for header mangling. 

You are arguing that we maintain a principle that we now know to be
misguided, that gets us away from header mangling but imposes most
of the same constraints on apps that header mangling does, and that
prevents IPv6 from solving the problems that were imposed by NATs.
This is not a step forward.

> You can't seem to see that the
> to use it, 

It does if globals are not available, or if the app is using an address
in a referral that was obtained from another app within the same site.

> while also insisting that apps that might want to run in a
> limited scope are invalid. 

Purely-local apps do exist, but that's a relatively small category 
of apps.  Most app designers and users want apps to be able to work 
(policy permitting) between any set of nodes.  And denying apps 
access to global addresses is a lousy way to implement this policy.

> No one is requiring the apps you write to use
> SL addresses.

Nobody except misguided network admins, and you.

Keith

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Nov 2002 20:29:50 +0100 (CET)

> APPLICATION REASON TO HAVE SL. 

Being the probable guilty party for introducing this thought back in
draft-*-site-prefixes-00.txt I can offer a slightly expanded perspective.

I don't think stable addresses per se is the key thing - it is
the robustness of the communication that is important.
This robustness has at least two factors that are relevant in this
discussion: the stability of the addresses, and the leakage of
non-global scope addresses. I think the question is how to weigh those
together.

In terms of the stability of the addresses one has to take into account
both stability as it relates to local communication and stability for
global communication. If you assume that the value/importance of local
communication is much higher than the value/importance of global communication
then site-locals make sense to explore. (FWIW that was my assumption
way back).
Such an assumption might make sense we say that a site is an
administrative concept (such as a company), but it makes less sense
if a site is a geographic concept and as I understand the original
thoughts a site was intended to be a geographic concept like a building
or a campus.
In any case, for a home user I suspect that the value/importance of
local communication would typically be less than the value/importance
of global communication. Thus the ISP offering a service with unstable
global addresses I don't think it would be that satisfactory
for the peer-to-peer communication that we wish to enable with IPv6,
even if there are stable site-local addresses so that the user can
communicate inside their home without a glitch.

Additionally, folks might want to use mobile-ipv6 and still get a quality
service. Since MIPv6 MNs are likely to use global addresses (presumably they
wish to be capable to move outside the home/site) their robust communication
require reasonably stable global addresses.

Finally, an enemy to robustness is complexity. Site-locals add complexity
in many places; applications, two-faced DNS configuration, etc.

So let's not loose sight of the fact that the goal is a robust network.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Mon, 18 Nov 2002 17:08:40 -0500

> So let's not loose sight of the fact that the goal is a robust network.

well said.  and offhand I don't see any reason to assume that SL addresses
are more stable/robust than globals.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------