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

From: "Bound, Jim" <[email-masked]>
Date: Tue, 12 Nov 2002 14:58:42 -0500

OK folks I am counting and I see clear majority for margarets proposal?

/jim
[In matters of style, swim with the currents....in matters of principle,
stand like a rock.  - Thomas Jefferson]

> -----Original Message-----
> From: Alain Durand [mailto:[email-masked]] 
> Sent: Tuesday, November 12, 2002 1:50 PM
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: Re: Proposal for site-local clean-up
> 
> 
> 
> 
> Brian E Carpenter wrote:
> 
> >Unfortunately it's too late to catch the addressing architecture 
> >document unless we recall it from the RFC Editor and cycle 
> it through 
> >the IESG again. But I propose that we do exactly that, in order to 
> >change the following paragraph in section 2.5.6:
> >
> [...]
> 
> >Alternatively, we could spend the next 5 years discussing the 
> >unnecessary complexities of using site-locals on connected sites.
> >
> >  Brian
> >
> 
> As I would like to see IPv6 deployed in my lifetime,
> I support proposal like this one that makes life simpler.
> 
> It's time to move on, unless the volume of discussion/rat 
> holing on this topic will really become a DOS attack on the 
> mailling list, or worse, on IPv6 itself.
> 
> - Alain.
> 
> --------------------------------------------------------------------
> 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: Tue, 12 Nov 2002 17:39:45 -0800

Turn your back to cover day-job issues for a couple of days, and all
hell breaks loose....

There is absolutely no reason to restrict SL to disconnected sites. If
someone wants to write an RFC on why they increase complexity for
multi-party apps, fine. That does not mean we need to significantly
change the architecture at the last minute, basically without serious
review and commentary. If that happens, expect a process appeal.

Tony

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bound, Jim
> Sent: Tuesday, November 12, 2002 11:59 AM
> To: Alain Durand; Brian E Carpenter
> Subject: RE: Proposal for site-local clean-up
> 
> 
> [In matters of style, swim with the currents....in matters of 
> principle, stand like a rock.  - Thomas Jefferson]
> 
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Nov 2002 20:48:38 -0500

> There is absolutely no reason to restrict SL to disconnected sites.

Tony, we've been discussing the reasons for weeks now.  It's pretty
disingeneous to say 'absolutely no reason' in the face of this.

Face it, SLs as originally conceived are broken.  This is the simplest fix.

Keith

---

From: Shannon -jj Behrens <[email-masked]>
Date: Tue, 12 Nov 2002 17:55:44 -0800

I haven't caught up with the whole thread (as can well be imagined), but I 
agree as well.

-jj

-- 
def qsort(l): # Purely functional implementation of QSort in Python.
    if not len(l): return []
    return (qsort([i for i in l[1:] if i < l[0]]) + [l[0]] + 
            qsort([i for i in l[1:] if i >= l[0]]))
--------------------------------------------------------------------
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: Tue, 12 Nov 2002 18:10:51 -0800

Keith Moore wrote:
> Tony, we've been discussing the reasons for weeks now.  It's 
> pretty disingeneous to say 'absolutely no reason' in the face of this.
> 

No, there has been a refusal to accept that the problems raised are
bogus in all but the multi-party app case. This is the only reason the
discussion has lasted this long. 

The fundemental issue here the architecture has been changed to support
multiple simultanious scopes. Those that are having a hard time figuring
out how to do that are opposed to SL, because that address range exposes
the issue. This is a new environment where we will be able to develop
apps that were not possible in the single-scope environment of IPv4.
Rather than close that off because it is not easy to grasp, document the
case of multi-party app issues and lets move on. 

Again, if the wording is changed to make a significant architectural
change during the RFC editor process, expect an appeal.

Tony

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Nov 2002 21:27:44 -0500

> multiple simultanious scopes. 

And it was taken too far before the consequences were understood.  
Now we're fixing this bug, and it's about time.

> Those that are having a hard time figuring
> out how to do that are opposed to SL

There is no difficulty in figuring out what to do.  We've figured it out
already.  There is a simple fix with few drawbacks and there are 
unacceptably complex fixes with numerous drawbacks.  It's a no-brainer.

> This is a new environment where we will be able to develop

No.  Scopes reduce the ablity of the network to support apps.
They make it harder to produce an app that works independently
of network location, and they don't add a single extra capability
that wasn't present already.

Why in the world you should be trying to promote dysfunction in the 
network is beyond me.  

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 12 Nov 2002 19:08:41 -0800

Keith Moore wrote:
> ...

I am not promoting dysfunction, that will happen for operational /
policy reasons. I am trying to make sure that when it does happen, there
is a clearly understood mechanism for identifying it.

Tony

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Nov 2002 22:41:23 -0500

> policy reasons.  I am trying to make sure that when it does happen, 
> there is a clearly understood mechanism for identifying it.

I don't see how SLs give you that.  The existence of SLs will not
obviate the need for other filtering in the network, simply because
they are too inflexible to serve a significant fraction of
filtering needs.  There is the risk that they will weaken security
by encouraging over-reliance on a mechanism that is too inflexible
for real-world use.  And SLs cannot reliably tell apps whether traffic 
can get from point A to point B.    

Keith

---

From: Richard Carlson <[email-masked]>
Date: Wed, 13 Nov 2002 10:48:52 -0600

Keith;

At 09:27 PM 11/12/02 -0500, Keith Moore wrote:
>[snip snip snip]

You keep saying that some apps will fail with scoped addresses.  My poor 
brain can't grasp why this is so.  Can you give me a detailed example of 
how an app will fail if it has multiple scoped addresses to choice from?  I 
don't mean that it may be hard to for the app to decide which address to 
use.  Yes that's a hard problem, and we don't have a solution to it yet, 
but that doesn't seem a good enough reason to kill site locals to me.  I 
also don't mean that an app can get confused and it will fail to connect to 
the correct proper destination if it uses a scoped address at the wrong 
time.  Yes this can happen, but it's still part of the address selection 
problem, not a basic problem with an app.

I'm looking for something like FTP and NAT.  FTP exchanges IP addresses in 
data messages which fail when NATs cause these addresses to change.  There 
are all kinds of kludges that try to work around this problem, but the 
basic issue is that the E2E property of IP was lost and the apps suffer for 
this change.

I don't see the same thing happening with site-local's, everyone agrees 
that they aren't a v6 NAT replacement so apps are not allowed to propagate 
site locals outside of the site boundary.  Yes, hosts need to be aware of 
the site boundary, but that is still an address selection problem not a 
problem with the app itself.  Site-locals are unique within the site 
boundaries and look just like a global IPv6 address, so what is a specific 
example where an app will be broken by using a site-local address?

Rich

>Why in the world you should be trying to promote dysfunction in the

------------------------------------

Richard A. Carlson                              e-mail: [email-masked]
Network Research Section                        phone:  (630) 252-7289
Argonne National Laboratory                     fax:    (630) 252-4021
9700 Cass Ave. S.
Argonne,  IL 60439

---

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

> how an app will fail if it has multiple scoped addresses to choice from?  

example 1:  Process A sends the addresses of process B to process C.
Processes B and C are in different scopes.  (Either one might or might 
not share a scope with A.)  Process C cannot communicate with process
B using SLs that it has received from A.

example 2:  A sends the addresses of B to C.  This time B and C are in
the same scope, but A does not have access to that scope.  If A sends
the SL addresses of B to C, C can talk to B.  However A has no way of
knowing whether this is the case.  If on the other hand A filters SLs
in addresses that it sends to C (as some have suggested is appropriate), 
C may be unable to talk to B for lack of an address that works, even 
though B and C share an address scope.

In either example the problem is solved if B and C have global addresses,
and all referrals filter SL addresses.  But that's not realistic given
current address allocation policies.  And if we change the address allocation
policies to permit any network to get a global prefix, there's even less
reason to have SLs.

> I don't mean that it may be hard to for the app to decide which address to
> but that doesn't seem a good enough reason to kill site locals to me.  

Standards-track protocols are supposed to have no known technical omissions
with respect to the requirements placed on them, and are supposed to have
resolved known issues.  An addressing architecture that expects apps to 
solve an unsolved problem that is acknowledged to be difficult doesn't 
seem like it meets either of those criteria.

> I also don't mean that an app can get confused and it will fail to connect to

Address selection doesn't solve this problem.  Basically what the app has
to do is implement its own addressing (so it can disambiguate hosts using
the same address) and routing (so it can operate across site boundaries - 
because this will be necessary for many apps).  

> site locals outside of the site boundary.  

No, everyone does not agree on that.  First because apps aren't aware of
topology so they don't know when they're propagating an address outside
of a site boundary.  Second because expecting apps to be aware of topology
imposes too much of a burden on those apps.  Third because if those apps 
don't have alternatives to using SLs they'll be forced to use them.  Fourth 
because if the apps reliably do have alternatives to SLs (for networks 
that aren't isolated) then there's not much reason to have SLs at all.

> Yes, hosts need to be aware of
> the site boundary, 

no, not hosts.  hosts aren't making those decisions.  apps are.

> but that is still an address selection problem not a

see above.

Keith

---

From: Richard Carlson <[email-masked]>
Date: Wed, 13 Nov 2002 17:21:23 -0600

Keith;

>though B and C share an address scope.

These are generic examples.  Please provide me with the name of one of 
these apps.  Also:

* why is A sending the B's IP address to C, why not send the FQDN or some 
other name and let C look up the address?

* How is this scenario different from the case where a filter blocks the B 
to C communications channel?  Wouldn't the app 'see' the same failure 
mode?  In this case the use of global addresses doesn't help does it?

>seem like it meets either of those criteria.

Standards track documents are suppose to describe the protocol operation in 
enough detail that inter-operable implementations can be written.  Where 
are the bake-off results that show that scoped addresses present an 
unsolvable problem?

>because this will be necessary for many apps).

I don't grog this answer.  Address selection policies is precisely the 
problem I think you're talking about.  If an app gets a list of addresses 
back from a name lookup query it somehow has to order these addresses and 
decide which ones to try and in what order.  Since a v6 host can have 
multiple globally unique addresses or a set of scoped addresses, the app 
must have some way of determining which address to use.  I would think that 
having a know set of scoped prefixes (Global, SL, LL) would make it easier, 
instead of harder for the app to start the sorting process.

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Nov 2002 19:35:32 -0500

> these apps.  

PVM.  NetSolve.  SNIPE.  probably Globus and Legion also.  SIP.
and for that matter, HTTP if it uses address literals in "moved 
temporarily" referrals and same-site image loading (which would 
make page loading *much* faster and more reliable)

> other name and let C look up the address?

because for some cases DNS is inherently too slow, too unreliable, too 
ambiguous, and/or not widely supported enough to use.  DNS query times
of several seconds are not unusual, failure rates are much worse than 
direct use of IP.  DNS names are often ambiguous, one name mapping to 
multiple hosts.  DNS names are sometimes scoped so that the same name 
doesn't have the same meaning everywhere.  

summary: it's unreasonable to expect all apps to use DNS all of the time.

also, pushing the problem to DNS doesn't actually solve the problem,
it just defines the solution in terms of another unsolvable problem. 

> mode?  In this case the use of global addresses doesn't help does it?

example 2 illustrates why just having nodes refuse to use SLs in 
referrals does not work in the absence of globals.  the app cannot 
support communication between B and C even though the network 
permits it, because it has used this filtering rule.

> are the bake-off results that show that scoped addresses present an 

you've got it wrong.  we know there are problems.  the burden is on those 
who think that scoped addresses don't cause problems to demonstrate that 
they're easily solved.  otherwise we don't meet the requirements in 2026.

> problem I think you're talking about.  

no, address selection doesn't solve the problems introduced by SLs.
and it can't possibly do so, because the information needed to make
the right choice about which address to use is not in general
available to the host that is making the selection.  

> If an app gets a list of addresses 

it makes it easier to get incorrect or suboptimal results, yes.
it doesn't make it easier to get the right result for that app.

Keith