Subject: Proposal for site-local clean-up

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Nov 2002 13:53:00 +0100

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:

Current text:

>    Site-local addresses are designed to be used for addressing inside of
>    a site without the need for a global prefix.  Although a subnet ID
>    may be up to 54-bits long, it is expected that globally-connected
>    sites will use the same subnet IDs for site-local and global
>    prefixes.

Proposed new text:

   Site-local addresses are designed to be used for addressing inside of
   a site which is not connected to the Internet and therefore does not
   need a global prefix.  They must not be used for a site that is connected
   to the Internet. Using site-local addresses, a subnet ID may be up to 
   54-bits long, but it is recommended to use at most 16-bit subnet IDs, 
   for convenience if the site is later connected to the Internet using a
   global prefix.

Otherwise, we will need a whole new RFC just for this paragraph.

Alternatively, we could spend the next 5 years discussing the
unnecessary complexities of using site-locals on connected sites.

  Brian
--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Tue, 12 Nov 2002 08:10:43 -0500

>Current text:

Hi Brian,

>    for convenience if the site is later connected to the Internet using a

I would support this change.  However, I doubt that we will get
consensus to make this change before the addressing architecture
is issued as an RFC.  I guess we'll see how things develop in
Atlanta.

>unnecessary complexities of using site-locals on connected sites.

This is _exactly_ what I am hoping to avoid.

Let's limit site-locals to the well-understood case, and focus on
solving the real problems:

         - Getting IPv6 finalized and ready for wide-scale deployment
         - Multi-homing
         - Renumbering
         - Security model for shared IPv4/IPv6 networks

Margaret

---

From: Brian Haberman <[email-masked]>
Date: Tue, 12 Nov 2002 09:12:15 -0500

>         - Security model for shared IPv4/IPv6 networks

I agree with Brian and Margaret.

Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Nov 2002 16:31:20 +0200 (EET)

> I agree with Brian and Margaret.

Also totally agree.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Nov 2002 17:14:26 +0200 (EET)

On Tue, 12 Nov 2002, Brian E Carpenter wrote:
[...]
> unnecessary complexities of using site-locals on connected sites.

Note that we will need at least one more RFC anyway, because we really 
have to try to nail this down with solid reasoning -- else, no matter what 
it says in the addrarch -- this thread keeps popping up again and again.
(I think this "reasoning draft" was already in progress -- good.) 

But as the addrarch is an RFC which will be frequently cited and read, 
it's good to have a statement there.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Nov 2002 08:06:35 -0800 (PST)

Count me in on agreeing with Brian too.

	 Mike

---

From: Alain Durand <[email-masked]>
Date: Tue, 12 Nov 2002 10:49:58 -0800

[...]

>unnecessary complexities of using site-locals on connected sites.

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.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 12 Nov 2002 15:09:09 -0500

I support this suggested course of action and the proposed new text.

- Ralph

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Nov 2002 16:39:30 -0500

I support this text.  

should "must not" be in upper case?

---

From: Mark Smith <[email-masked]>
Date: 13 Nov 2002 09:49:41 +1100

I support this change and the new text.

Mark.

---

From: Rob Austein <[email-masked]>
Date: Tue, 12 Nov 2002 18:43:36 -0500

What Brian C., Margaret, Brian H., Pekka, Mike, Jim, Alain, Ralph,
Keith, and Mark said, but not what Brian Z. said :).
--------------------------------------------------------------------
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: Randy Bush <[email-masked]>
Date: Tue, 12 Nov 2002 15:50:40 -0800

> Keith, and Mark said, but not what Brian Z. said :).

what he said

---

From: [email-masked]
Date: Wed, 13 Nov 2002 09:39:06 +0900

>   for convenience if the site is later connected to the Internet using a

	i'm happy with the change.

itojun

---

From: John Bartas <[email-masked]>
Date: Tue, 12 Nov 2002 16:57:43 -0800

Hi,

	What they said.

	I mean, I support Brian's wording change in the RFC. Being a newbie on
this list I probably shouldn't get a vote, but being a newbie I may have
a new perspective. A lot of the networking world sees IPv6 as still
thrashing and not ready for prime time. A year ago I read RFC-3056 (good
work, Brian), and concluded that it may be be time for my company to
devote resources to it. We have, and it's been a learning experience. 

	Personally I'm not thrilled about the idea of SL addresses. They seem
to wrap the IPv6 design around "corporate campus" type networks as they
existed in the mid 1990s, and thus handicap IPv6's ability to adapt to
future hierarchy evolution as well as v4 did. However making a change so
severe as to require re-coding IPv6 stacks (which seems to be where some
of the proposals could end up) will hurt IPv6's market credibility more
than it will help anything. Brian C.'s change would not require recoding
our stack (nor I think most others), but it does clear up some of the
ambiguity around SL addresses that I had after first reading the RFC.
That seems like the best we can hope for.

	As Brian Z. pointed out, I'd be a bit miffed if the stack we just got
done writing (to be RFC compliant) required a change of this sort before
we even get it out of Beta. Maybe a good Mantra for this group to get
IPv6 accepted widely would be:

	"If it ain't fatal, don't fix it". 

-JB-

(BTW, Hi Rob!)

-- 
-JB-

#############################################################
          H
(==)o(==) H John Bartas - Main Propeller head
   _I_    H InterNiche Technologies Inc. (408) 257-8014 x219
  /   \   H 1340 S. DeAnza Blvd. Suite 102
  -----   H San Jose CA 95129
   O O    H [email-masked]
    "     H www.iniche.com
  \___/   H
--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 13 Nov 2002 15:34:40 +0900

>>>>> On Tue, 12 Nov 2002 13:53:00 +0100, 
>>>>> Brian E Carpenter <[email-masked]> said:

>    for convenience if the site is later connected to the Internet using a

I'm personally okay to restrict the use of site-local addresses
(though the level of the restriction may need to be discussed).

However, the proposed text seems to introduce a big impact on the
current usage of SLs in spite of the small change on wording; it
restricts the use to non-connected networks.  This type of proposal
has been raised in this thread several times, and we've seen doubts
and objections to the proposal every time (of course, as well as
agreement).  

So, I'm a bit surprised that a majority of this group is going to
support the proposed text, even by those who had a doubt such as "I
personally would like to deprecate site-local addresses, but I'm not
sure if it is effective to impose such a big change on the current
usage."

I admit I've not read all the messages in this huge thread, but please
let me ask: has there been a consensus in the thread to limit the use
of site-locals to not-globally-connected networks?  If so, I'll follow
the consensus, and will just be happy.  Otherwise, I'd say we have to
be careful because we'll easily go into the same loop of discussion.

I'd also like to point out a few things (some of them have been
covered by the discussion so far):

- the case of multi-sited nodes, which is a major sources of
  headaches, is not eliminated even if we can restrict the usage to
  non-globally-connected networks.  What should we do on this topic?
- though I'm okay to restrict the use of SLs (as I said above), I'm
  not sure if the proposed limitation is effective.  What exactly does
  the "must not" mean?  Does it mean nodes in the global network must
  drop packets contains SLs?  How can we ensure the restriction?  How
  can the nodes detect if they are in the global network?  What should
  we do when our network using SLs connects to the global network?

Having considered the points above, my honest feeling is that the
proposal is an incomplete compromise.  The impact is as big as a
stronger change of deprecating SLs *completely*, but there will still
remain difficult issues.  If we have really reached a consensus on the
proposed text, I guess we can even agree on removing SLs completely,
with which I'll be much happier.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[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: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 13 Nov 2002 10:35:07 +0100

I think Brian's proposal, if adopted, makes my worry about site-locals 
inducing complexity in naming lookup mechanisms go away (naming mechanisms 
for disconnected networks have to be different from those for connected 
networks anyway).

So you can count me as supporting the proposal.

That said, I also think that writing down (some of) the arguments on the 
issue in permanent form would be a good idea...... and there are a few 
devils-in-the-details having to do with the transition between 
connectedness and disconnectedness, which also could use some 
words-on-electrons.

But this resolution seems basically right to me.

                    Harald

--On tirsdag, november 12, 2002 13:53:00 +0100 Brian E Carpenter 
<[email-masked]> wrote:

>    need a global prefix.  They must not be used for a site that is
> connected    to the Internet. Using site-local addresses, a subnet ID may
> be up to     54-bits long, but it is recommended to use at most 16-bit
> subnet IDs,     for convenience if the site is later connected to the
> Internet using a    global prefix.
>

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 13 Nov 2002 10:48:01 +0100

If I could sleep assured that site-locals would not be used for any 
other network than networks not connected to global Internets, I would 
be all for this. What still have me really worried is that there is no 
way to enforce this, and it is just inviting NATv6.

In that case Brians wording will just help get the document published 
and end the discussion without anyone having gained anything.

Then again, there is no way we can stop people from doing NAT even with 
global addresses....

I guess I am for this proposal as well then...

- kurtis -

On onsdag, nov 13, 2002, at 10:35 Europe/Stockholm, Harald Tveit 
Alvestrand wrote:

> inducing complexity in naming lookup mechanisms go away (naming 
> mechanisms for disconnected networks have to be different from those 
> for connected networks anyway).
>
> That said, I also think that writing down (some of) the arguments on 
> the issue in permanent form would be a good idea...... and there are a 
> few devils-in-the-details having to do with the transition between

---

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

> remain difficult issues.  

I agree that there remain difficult issues even with this restriction
in place.  SLs are still allowed, for instance, on networks that connect
to other networks, and this will still break apps that operate between
those networks.

And yet I don't see how to deprecate SLs completely until we have a
solution in place to allow networks that are not connected to the
Internet to get global address space.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Nov 2002 15:54:16 +0100

Well, there are far more people saying yes than no, but let me
respond to some of the comments made.

1. Process (Tony Hain). Of course. If we make a substantive change
to a draft that's already passed the IESG, a last call is needed IMHO. It
would still be cleaner than publishing the RFC and then publishing a
change.

2. Rationale. (several people). Yes, it might be good to publish
an informational document about this. That might well belong in v6ops.

3. Can't stop NAT's anyway. (several people). That may sadly be true,
but we shouldn't publish specs that seem to encourage them.

4. Impact on existing implementations and ongoing work. (several
people). I don't really understand what the implementation change would
be - surely this is basically a configuration issue? Products will
still have to support SL. If we are going to impact ongoing work,
however, the sooner the better.

5. Why not just kill SL completely? (JINMEI) That would definitely
annoy implementors, and close off our options.

6. We have to handle multiple scopes anyway (Brian Zill, Tony Hain).
Right. And by retaining SL, we retain the option of reversing the
"disconnected" decision if we ever do figure out how to handle
them properly.

7. must not v. MUST NOT (Keith Moore). The document as a whole doesn't
use upper case.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
--------------------------------------------------------------------
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: Vladislav Yasevich <[email-masked]>
Date: Wed, 13 Nov 2002 10:44:18 -0500

>    for convenience if the site is later connected to the Internet using a

I have some reservations about this this proposal from the implementors
point of of view.

The proposal uses the words "must no" (lower case) and that makes it
somewhat unclear and brings up the following questions.

If the implemenation supports the use of site-locals when a global prefix
is availiable and the node is connected to the "global internet", is the 
implementation compliante with the addr-arch?

If the node is configured with both site-locals and globals, is the
configuration addr-arch compliant?

IMHO, it would almost be easier to remove the "must not be used" sentence
from the above paragraph.

-vlad
-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Nov 2002 18:09:10 +0100

> from the above paragraph.

Yes, I like that suggestion. It's consistent with Harald's comment
that we don't have an enforcement department.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 Nov 2002 09:30:23 -0800

Brian,

I don't think it is wise to ask the IESG to reconsider the address 
architecture (this is more than an editorial change to the RFC-editor).  I 
also think the issues regarding the usage of site-local are more 
complicated that can be expressed in a paragraph.

I don't think we will get a consensus on this one way or another.  This is 
IMHO about people making different benefit vs. complexity tradeoffs.  Like 
many other things in the IETF that there is disagreement on, I think it is 
better to document what it is and why it isn't a good idea and move on.

Bob

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 13 Nov 2002 09:46:20 -0800

Brian E Carpenter wrote:
> Well, there are far more people saying yes than no, but let 
> me respond to some of the comments made.
> 
> 1. Process (Tony Hain). Of course. If we make a substantive 
> change to a draft that's already passed the IESG, a last call 
> is needed IMHO. It would still be cleaner than publishing the 
> RFC and then publishing a change.

The way I read the thread, the plan was to simply change a few words in
the RFC editor queue. In any case, this is more than a few words, it is
a major architectural change and would require recycling to the WG & PS.

> 
> 2. Rationale. (several people). Yes, it might be good to 
> publish an informational document about this. That might well 
> belong in v6ops.
> 
> 3. Can't stop NAT's anyway. (several people). That may sadly 
> be true, but we shouldn't publish specs that seem to encourage them.

Preventing simultaneous use of SL & Global will in fact encourage NAT.
Network managers require that some nodes are invisible to the global
network. Most will find it easier to force the systems that need public
access to use NAT, rather than try to maintain a lengthy filter list at
the border for those that don't. Giving them the tool that allows easy
filtering, with simultaneous with global addresses for those nodes that
need it, is the only real way to avoid NAT. 

> 
> 4. Impact on existing implementations and ongoing work. 
> (several people). I don't really understand what the 
> implementation change would be - surely this is basically a 
> configuration issue? Products will still have to support SL. 
> If we are going to impact ongoing work, however, the sooner 
> the better.

This is not a simple address format change, it is a major architectural
issue. All the implementations that already know how to deal with
simultaneous scopes will have to do major surgery strip that out, or
ship non-compliant code.

> 
> 5. Why not just kill SL completely? (JINMEI) That would 
> definitely annoy implementors, and close off our options.
> 
> 6. We have to handle multiple scopes anyway (Brian Zill, Tony 
> Hain). Right. And by retaining SL, we retain the option of 
> reversing the "disconnected" decision if we ever do figure 
> out how to handle them properly.

People already know how to deal with 'connected' 1918 space, this is no
different in that respect. What is different is the architectural change
to support simultaneous use of multiple scopes. This is not rocket
science, it just requires working through the engineering of the new
edge cases.

Tony 

> 
> 7. must not v. MUST NOT (Keith Moore). The document as a 
> whole doesn't use upper case.
> 
>    Brian
> 
> Brian E Carpenter wrote:
> > 
> > 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:
> > 
> > Current text:
> > 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> - - Brian E Carpenter

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Nov 2002 10:05:49 -0800 (PST)

So I have a question for those who support
connected site locals: what would prevent a new
RFC from updating Brian's wording for site locals
(if that's the right thing)?

I say this because it seems to me that there's a
lot of issues being conflated in these arguments
and what's sort of frightening to me is that they
need to be teased apart. In particular, the desire
for provider independent addressing seems to
factor in here fairly largely too, and I wonder if
the better part of valor might not be to get
together a BOF which focuses on the actual real
life requirements here. It's possible that site
locals in the end might make sense here, but it's
also possible that it can be done other ways too
(or that the entire problem is totally intractable
which is the way it looks to me now).

	 Mike

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 13 Nov 2002 10:57:38 -0800

So much traffic has flown by on this subject that my head is still spinning.
But, let me give one example in which the use of site-locals on globally
connected networks might be useful.

While at SRI International, I had the privilege of participating in a study of
autonomous teams of unmanned vehciles with the Office of Naval Research. Such
teams may consist of hundreds/thousands of mobile vehicles that travel together
in a more-or-less coordinated fashion. Communications are nicely modeled by
Mobile Ad-hoc Networking, as in the IETF MANET WG. Very large teams may be
organized into "clusters" based on geography, commonalities of interest,
etc. Finally, the team as a whole is only intermittently connected to the
global Internet - perhaps with long periods of disconnected operation.

When the team is out of contact with the global Internet, site-locals can provide
a nice means to facilitate intra-cluster and inter-cluster communcations. When the
team comes in contact with an access router(s) to the the global Internet, the global
prefixes can be disemminated to team members that need global access. But since the
team is mobile, global access may be intermittent, with new global prefixes learned
as different access routers are encountered.

So it seems tome that site-locals can provide a useful mechanism for large mobile
networks with intermittent global connectivity.

Fred Templin
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 13 Nov 2002 11:08:41 -0800

FWIW,

This study, along with others in the US Army CECOM division,
produced the transition mechansim now known as ISATAP.

Fred Templin
[email-masked]

---

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

> that we don't have an enforcement department.

Well, I don't think the paragraph is sufficient without it.  

How about saying that 

- SLs are known to cause problems for DNS and other applications
- the security benefits of SL are dubious and marginal at best
- until the issues associated with exposing applications to mixed 
  scopes are better understood, SLs SHOULD NOT be used on networks
  that also use global addresses?

Keith

---

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

> a major architectural change and would require recycling to the WG & PS.

We don't normally require recycling to proposed when we fix bugs in
a standards-track document while it advances.  Indeed, that's the 
reason we advance documents in grade - so we can revise them in light
of mistakes discovered in earlier versions.

Nor is there anything in the process that requires documents to be 
recycled to a WG when bugs are found - in most cases the WG is no
longer around.  How the document is handled is up to IESG.

> Preventing simultaneous use of SL & Global will in fact encourage NAT.

no, not "in fact".  that's just a figure of speech.

> the border for those that don't. 

Neither SL nor NAT will save those sites from having to maintain a filter
list.  If some hosts on network are allowed to be exposed to the outside
and others aren't, the list of exceptions has to be maintained somewhere.

> Giving them the tool that allows easy

But the only way to make SLs work on a network that has external connections
is to give all nodes global addresses.  You can't just assign "global
addresses for those nodes that need it" without burdening apps that need
to talk to the other hosts with having to do their own addressing and 
routing.  

The strategy that you are advocating is precisely what we need to discourage.
It's no better than NATs.  If it's widely adopted it will destroy the
additional utility that IPv6 provides over IPv4.

If sites want to use NAT they should stick with IPv4.

> simultaneous scopes will have to do major surgery strip that out, or

No they won't.  It will just be code that isn't exercised.

And I disagree that there are implementations that "know how to deal
with simultaneous scopes".  Those implementations are almost certainly
making unwarranted assumptions (or imposing unreasonable constraints, 
if you prefer) about how people organize their networks.

> People already know how to deal with 'connected' 1918 space, 

No they do not.   There is no general solution, there are lots of
hacks that work only for constrained cases.  The closest thing to 
a general solution is Teredo, but even that will fail if SLs 
are widely used in IPv6.

> this is no

First of all, it's not engineering, since we don't yet know how to
solve the problem.  Second, there isn't enough benefit to justify
the investment in the effort much less the burden on applications.

Keith

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Nov 2002 20:30:03 +0000

Hi Fred,

That's interesting.  There has been some talk about multiple ISATAP site
routers, and scalability.  Can you comment on how ISATAP performed in this
network of thousands of (mobile) hosts?  (I assume you meant hundreds or
thousands, not hundreds of thousands)

Tim

---

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

Keith Moore wrote:
> > > to a draft that's already passed the IESG, a last call is needed 
> > > IMHO. It would still be cleaner than publishing the RFC and then 
> > > publishing a change.
> > 
> > The way I read the thread, the plan was to simply change a 
> few words 
> > in the RFC editor queue. In any case, this is more than a 
> few words, 
> > it is a major architectural change and would require 
> recycling to the 
> > WG & PS.
> 
> We don't normally require recycling to proposed when we fix 
> bugs in a standards-track document while it advances.  
> Indeed, that's the 
> reason we advance documents in grade - so we can revise them 
> in light of mistakes discovered in earlier versions.
> 
> recycled to a WG when bugs are found - in most cases the WG 
> is no longer around.  How the document is handled is up to IESG.

This is not a bug, it is an architectural principle. Those are not
changed on a whim after the review process has completed.

> 
> > > 3. Can't stop NAT's anyway. (several people). That may sadly be 
> > > true, but we shouldn't publish specs that seem to encourage them.
> > 
> > network. Most will find it easier to force the systems that need 
> > public access to use NAT, rather than try to maintain a 
> lengthy filter 
> > list at the border for those that don't.
> 
> Neither SL nor NAT will save those sites from having to 
> maintain a filter list.  If some hosts on network are allowed 
> to be exposed to the outside and others aren't, the list of 
> exceptions has to be maintained somewhere.

Yes, but putting that in the address allocation process scales better
than having to scan a 10,000 entry list for each packet.

> > filtering, with simultaneous with global addresses for those nodes 
> > that need it, is the only real way to avoid NAT.
> 
> But the only way to make SLs work on a network that has 
> external connections is to give all nodes global addresses.  
> You can't just assign "global addresses for those nodes that 
> need it" without burdening apps that need to talk to the 
> other hosts with having to do their own addressing and 
> routing.  

Read draft-ietf-ipv6-default-addr-select-09.txt for instructions on
sorting that out.

> 
> The strategy that you are advocating is precisely what we 
> need to discourage. It's no better than NATs.  If it's widely 
> adopted it will destroy the additional utility that IPv6 
> provides over IPv4.

How does use of unmolested global addresses become what we have today?
Nodes that need global access get a global address for that along with a
SL for internal use, and those that don't get only a SL.

> > > people). I don't really understand what the implementation change 
> > > would be - surely this is basically a configuration 
> issue? Products 
> > > will still have to support SL. If we are going to impact ongoing 
> > > work, however, the sooner the better.
> > 
> > This is not a simple address format change, it is a major 
> > architectural issue. All the implementations that already 
> know how to 
> > deal with simultaneous scopes will have to do major surgery 
> strip that 
> > out, or ship non-compliant code.
> 
> And I disagree that there are implementations that "know how 
> to deal with simultaneous scopes".  Those implementations are 
> almost certainly making unwarranted assumptions (or imposing 
> unreasonable constraints, 

On the contrary, they are providing the tool that allows people to get
maximum value from the networks the way they are currently organized.

> definitely 
> > > "disconnected" decision if we ever do figure out how to 
> handle them 
> > > properly.
> > 
> hacks that work only for constrained cases.  

So rather than lots of hacks, we should have formal documentation of the
approaches and constraints.

> The closest thing to 

Orthogonal & absurd comment since Teredo is about global prefixes. 

> 
> > this is no
> > different in that respect. What is different is the architectural 
> > change to support simultaneous use of multiple scopes. This is not 
> > rocket science, it just requires working through the engineering of 
> > the new edge cases.
> 
> First of all, it's not engineering, since we don't yet know 
> how to solve the problem.  Second, there isn't enough benefit 
> to justify the investment in the effort much less the burden 
> on applications.

One opinion that is not supported by current implementations.

Tony

---

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

> which is the way it looks to me now).

Some of the uses for SL would be better served by PI addresses, but not
all. 

Take the case of a 20,000 node network where half are allowed global
access and half are not. It is much more complex to sort through a
10,000 node list per packet for access filtering than it would be to
have two entries, SL deny & PA allow. Yes the list of which 10,000 nodes
are allowed the global prefix has to be maintained, but it can be
applied according to allocation policy rather than per packet
processing. 

Yes we need a PI format, and there are a few being batted around on
multi-6, but even there we are into engineering trade-offs about
allocation efficiency vs. routing table exception handling efficiency.
My intent was to bring a PI format proposal to this wg after multi-6
established requirements, but that wg seems to have been derailed into
the long running saga of overhauling the entire protocol suite. If there
is interest in discussing a PI format to get that off the table for the
SL discussion, I will ask the chairs to consider it as a WG doc.

Tony

---

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

> changed on a whim after the review process has completed.

Come on, Tony.  If we have a "principle" that justifies burdening 
applications with unnecessary complexity for dubious and marginal 
gain, aren't we better off without it?  

> than having to scan a 10,000 entry list for each packet.

No it doesn't.  Because if you can allocate SL+global addresses for some 
hosts and only SLs for others, then you can just as easily allocate 
different kinds of globals (say type A and B) for each host, and filter 
out just those that match type A.   

> Read draft-ietf-ipv6-default-addr-select-09.txt for instructions on

That draft is just WRONG for large numbers of applications.  The 
only way it was justified at all was by calling it a default,
saying that apps could take exception to it, and claiming that 
the need for consistency between implementations required us to 
to get default behavior defined now, even if it was known to be 
insufficient.

> SL for internal use, and those that don't get only a SL.

Today apps are expected to communicate between nodes even though those 
nodes don't have global addresses.   The people who make the decision
to deploy NATs and/or to use RFC 1918 addresses aren't aware of the 
detailed needs of applications - so they create dysfunctional networks,
and the app developers are expected to take up the slack.  Why will
those people be any wiser with their use of SLs?

And why should we not learn from our past experience with RFC 1918
and NATs and discourage practices that we now know to be harmful? 

> > unreasonable constraints, if you prefer) about how people organize 
> > their networks.
> 

They allow *some* people to get more (not maximum) value from *some* 
networks.  It's not reasonable to burden all users and networks 
for the long term in order to accomodate those few who have organized 
their networks poorly in the short term.

> approaches and constraints.

No, Tony.  You can't solve the problem simply by documenting the hacks
and when they work, because they're still hacks, they still don't work
well, and they still impose a lot of complexity.  And if the situation 
is that difficult to document then there's a good chance that it's too 
complex to use.

> Orthogonal & absurd comment since Teredo is about global prefixes. 

No, you're just missing the point.  Teredo is pretty much what you 
have to do if you want to produce a general solution for interoperation 
between networks with scoped addresses.  In other words, you have to 
define a new set of unambiguous addreseses and tunnel between the 
networks.  You don't necessarily need the mechanisms in Teredo to 
force the NATs to keep mapping state, but you need the rest.

The point is we just got finished figuring out how to use IPv6
to  allow IPv4-based networks to escape their dysfunction - and now
you're trying to impose most of that same dysfunction on IPv6.

> One opinion that is not supported by current implementations.

Only if you consider only the very few apps that try to deal with
SLs in a general fashion and ignore the large numbers of apps that
cannot deal with them.  And only if you ignore the huge amount of
complexity that has gone into solving the problems caused by use of
RFC 1918 (even without NAT) without a general solution.

Actually, the fact that you're trying so hard to preserve complexity 
that isn't needed unless SLs are imposed on the net argues strongly 
for getting rid of SLs.  Who benefits from that increased complexity?
Certainly not the network administrators or the users.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Nov 2002 13:11:28 -0800 (PST)

> Some of the uses for SL would be better served by PI addresses, but not

   Well, that's sort of my point. The fact these are
   intertwined in many cases seems like a good reason
   for prudence. If PI addresses could be made to
   work, a *lot* of the motivators for SL would go
   away and we could then consider the remaining
   cases independently. However, if we allow the
   current language it's going to be even more tangled
   up if we ever get PI's with an even bigger mess
   to sort through, not to mention the spectre of
   real deployment too.
 
 > applied according to allocation policy rather than per packet

   Why couldn't you use a reverse VPN? Ie, an SA is required
   between you and the inside edge for external access?

	       Mike

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 13 Nov 2002 16:20:33 -0500

>applied according to allocation policy rather than per packet

How are you planning to configure and organize these 20,000 nodes?

If the private nodes are randomly distributed around the network,
I certainly think that I'd rather configure an access list with
10,000 addresses and run autoconfiguration, then configure an
access list with one prefix and have to support DHCP or manual
configuration for all 20,000 nodes, but YMMV.

If the private nodes are organized into private and public
subnets, so that you could use autoconfiguration with site-local
addresses on some networks and global addresses on others, then
why would you need site-locals for that?  You could just advertise
two different global prefixes, and filter one of them...

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 13 Nov 2002 13:32:45 -0800

> gain, aren't we better off without it?  

Unnecessary, dubious, & marginal are one perspective. The point is that
the recommendation to preclude simultanious use of SL & global is a
serious architectural change. It is not a minor edit.

> maintain a 
> > > filter list.  If some hosts on network are allowed to be 
> exposed to 
> > > the outside and others aren't, the list of exceptions has to be 
> > > maintained somewhere.
> > 

Using what routing technology ??? If there are devices sitting on the
same wire, they need to have some coorelation in the address space for
current routing protocols to deliver packets.

> 
> > > But the only way to make SLs work on a network that has external 
> > > connections is to give all nodes global addresses. You can't just 
> > > assign "global addresses for those nodes that need it" without 
> > > burdening apps that need to talk to the other hosts with 
> having to 
> > > do their own addressing and routing.
> > 

For apps that it is insufficient, apply a rule that says SL is not an
acceptable choice. That is a local app decision.

> 
> > > The strategy that you are advocating is precisely what we need to 
> > > discourage. It's no better than NATs.  If it's widely adopted it 
> > > will destroy the additional utility that IPv6 provides over IPv4.
> > 
> > Nodes that need global access get a global address for that 
> along with 
> > a SL for internal use, and those that don't get only a SL.
> 
> detailed needs of applications - so they create dysfunctional 
> networks, and the app developers are expected to take up the 
> slack.  Why will those people be any wiser with their use of SLs?

Because with 1918 & nat, they have no choice about the matter. Telling
them they can't have a tool that will allow apps to work where required,
while breaking those that should be broken, is not getting to where you
want to go. They will insist on nat because filtering takes precidence
to making apps work for a subset of nodes. 

> 
> And why should we not learn from our past experience with RFC 
> 1918 and NATs and discourage practices that we now know to be 
> harmful? 

Preventing the SL space does not discourage the practice, preventing
simultaneous use of SL & global does. Filtering will be the priority,
and if the filter list is unwieldy, nat will take its place. 

> their networks poorly in the short term.

No one is requiring that SL be used, so the assertion that everyone has
a burden is absurd.

> > So rather than lots of hacks, we should have formal 
> documentation of 
> > the approaches and constraints.
> 
> No, Tony.  You can't solve the problem simply by documenting 
> the hacks and when they work, because they're still hacks, 
> they still don't work well, and they still impose a lot of 
> complexity.  And if the situation 

Documenting the hacks will expose the goals, which could in turn lead to
better engineering.

> force the NATs to keep mapping state, but you need the rest.

You are arguing that an app needs to work over a global scope, despite
the network manager's intention that it not. The point of scoping is to
prevent interoperation across the boundary.

> 
> The point is we just got finished figuring out how to use 
> IPv6 to  allow IPv4-based networks to escape their 
> dysfunction - and now you're trying to impose most of that 
> same dysfunction on IPv6.

The point is that the network manager intends some aspects of the
network to be broken. The tool we have provided to allow that to happen
without requiring all nodes to be subject to the brokenness is SL.

> Only if you consider only the very few apps that try to deal 
> with SLs in a general fashion and ignore the large numbers of 
> apps that cannot deal with them.  And only if you ignore the 
> huge amount of complexity that has gone into solving the 
> problems caused by use of RFC 1918 (even without NAT) without 
> a general solution.
> 
> for getting rid of SLs.  Who benefits from that increased 
> complexity? Certainly not the network administrators or the users.

It is not increased or decrease complexity. It is simply moving the
complexity around so that nodes that should not be subjected to
draconian policies have an out. The benefit is for those nodes that need
global accessability but have to share infrastructure with devices that
should not have public access. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 13 Nov 2002 13:46:17 -0800

Margaret Wasserman wrote:
> ...

The ones that should not have public access would be configured to only
listen for the SL prefix in an RA, or could be fed by DHCP. 

> 
> If the private nodes are randomly distributed around the 
> network, I certainly think that I'd rather configure an 
> access list with 10,000 addresses and run autoconfiguration, 
> then configure an access list with one prefix and have to 
> support DHCP or manual configuration for all 20,000 nodes, but YMMV.

Depends on the local network and its configuration capabilities. There
are environments where it is possible to use autoconfiguration, with a
policy constraint on restricted access nodes that says only accept a SL
prefix.

> subnets, so that you could use autoconfiguration with 
> site-local addresses on some networks and global addresses on 
> others, then why would you need site-locals for that?  You 
> could just advertise two different global prefixes, and 
> filter one of them...

I agree, but that requires specific topology constraints that are
unreasonable. If my laptop needs to be publicly accessable but my
printer does not, why is it reasonable to require separate network drops
rather than letting them share a hub?

Tony

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 13 Nov 2002 14:02:18 -0800

Keith Moore wrote:
>>Finally, the team as a whole is only intermittently connected to the
> yes, intermittent connection is one of the genuinely valid justifications
> for SLs.

Glad to hear you agree.

> however even with intermittent connection it is often possible to use
> globals rather than SLs.  the exception is a nomadic network that 
> connects to the net at different locations at different times, and
> whose hosts don't have home agent(s) for mobile IP.

This is exactly the case my message describe, modulo your point
"whose hosts don't have home agent(s) for mobile IP", which I don't
see as being relevant. In the case I described, two models are possible:

  1) The node's "home" is the MANET itself
  2) The node has a distant home and is always a visitor
     in whichever MANET it is currently in

Either way, when associated with a MANET that is currently disconnected
from the global Internet, site-locals seem like a nice feature.

Fred
[email-masked]

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 13 Nov 2002 16:54:52 -0500

Hi Tony,

>serious architectural change. It is not a minor edit.

I'm not sure where the concern is coming from that we will make
a major change to the addressing architecture during the RFC
editing phase.  Neither Bob nor I have proposed or advocated that
course of action.

You and I may disagree on whether or not this change is warranted,
and we may disagree about whether it is a major architectural change
or just a usage restriction, but we do agree on one thing...

This _would_ be a substantive change to the addressing architecture.

So, I would _not_ support making this change without rough WG consensus
and proper WG and IESG review, and I'm sure that Bob wouldn't either.

I hope that this addresses your concern in that area.

Margaret

---

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

> Unnecessary, dubious, & marginal are one perspective. 

It's a perspective supported by a lot of people and a lot of work.

> The point is that

It's a minor change to the text, and a serious architectural improvement.  

It doesn't break much that exists now, and it helps a lot of things 
to avoid being broken in the future.

> > No it doesn't.  Because if you can allocate SL+global
> > addresses for some hosts and only SLs for others, then you can 
> > just as easily allocate different kinds of globals (say type A and 
> > B) for each host, and filter out just those that match type A.
> 

Only in the most significant bits.   If an admin wants to assign some
bits within a subnet allocation for this purpose, he's free to do so.
Once you start having RA respond differently to different hosts on
a subnet there are all kinds of games you can play.

> acceptable choice. That is a local app decision.

That doesn't work for all apps, if SLs are widely used.  Some apps
would need to use SLs, others would need to avoid SLs.  It gets even
more complex than that when you consider privacy addresses, link 
locals, and multiple global prefixes. 

> > Today apps are expected to communicate between nodes even 
> > though those nodes don't have global addresses.   The people who 
> > make the decision to deploy NATs and/or to use RFC 1918 addresses 
> > aren't aware of the detailed needs of applications - so they create 
> > dysfunctional networks, and the app developers are expected to take 
> > up the slack.  Why will those people be any wiser with their use of SLs?
> 
> want to go. 

No, I'm not telling them that.  I'm saying that SL is not a good tool
for that job, that it does far more harm than good.  Because SL doesn't
allow those apps to work where required and break those that should
be broken.   It breaks some apps that shouldn't break and forces other
apps to circumvent SL restrictions which make SL even less useful 
as a mechanism for advertising policy. 

> and if the filter list is unwieldy, nat will take its place. 

There are ways to keep filtering from being unwieldy without forcing
apps to choke down SLs.

> No one is requiring that SL be used, so the assertion that everyone has

no one is requiring that NAT be used, so the assertion that everyone has
a burden of dealing with NATs would be absurd - if it weren't widely
accepted that NATs should be used.

if SLs are permitted in networks with globals then people WILL require
that they be used - whether or not this provides any useful security
and whether or not this allows applications to work reliably. 

> Documenting the hacks will expose the goals, which could in turn lead to

We already know how to do better engineering for this (which after all 
is about providing a sound way to solve the problems with the lowest cost)   
Discourage use of SLs on networks that have globals.  Don't claim that 
they are a useful security mechanism.  Tell apps that do referrals not
to use them.  Provide as many hosts as possible with globals.

> prevent interoperation across the boundary.

Existing apps are expected to work over global scope even though they are 
operating on networks isolated by NATs and using RFC 1918 addresses -
often because the network manager *thinks* this provides him some measure
of increased security.  He's generally wrong about that, for several reasons.

So I'd say no, the point of scoping is not to prevent interoperation of 
apps across that boundary, since for many apps on many hosts interoperation 
across that boundary is quite often found to be desirable.  Scoping is a 
really poor tool for that kind of access control.

The real point of scoping is security through obscurity - trying to pretend 
that those internal hosts don't exist, by hiding their addresses from the 
outside world, and by preventing external hosts from doing traffic analysis.  
And to some extent doing that might be desirable.  But we have better
mechanisms for solving that problems - mechanisms that aren't imposed for all
apps on a host.

> without requiring all nodes to be subject to the brokenness is SL.

And what we've found out is that it's a really crude tool.  Not only
is it too inflexible to serve this purpose, its use does a lot of harm.
 
> draconian policies have an out. 

No, it's making both apps and network filters more complex by forcing
apps to do the job of the network.

> The benefit is for those nodes that need

It's not just the nodes that need global accessibility that are affected;
those that communicate through intermediaries are also harmed by lack
of a uniform address space.

Keith

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 13 Nov 2002 14:18:05 -0800

Tim Chown wrote:
> network of thousands of (mobile) hosts?

I don't have any scaling figures from actual experiments, but scaling is
bounded by the frequency of the polling interval for router advertisements.
The spec currently lists 15min as the recommended minimum, so a density
of 900 nodes per ISATAP router would produce 1 RS/RA exchange per second.
Additional overhead is incurred for nodes that are actiively using the
router to carry traffic vis-a-vis NS/NA exchanges, but that overhead
is the same as for peer-peer communications between nodes.

If a generalized path MTU discovery mechanism were deployed, there would
be still more overhead for the tunnel encapsulator and decapsulator to
police the path MTU of the tunnel. But, I strongly believe that generalized
path MTU discovery is *not a good thing* for wireless networks. Reason
being - large packets on a lossy media (e.g., IEEE 802.11) incur increased
exposure to bit error rates, probability of loss, delay variance, etc. So,
there is no good reason to incur the extra overhead for generalized path
MTU discovery on such media - this also saves state in the routers.

(I assume you meant hundreds or thousands, not hundreds of thousands)

In a single cluster - hundreds or thousands. In a large MANET with
clustering - hundreds OF thousands or more. You also need to get into
analysis of the relative density/sparseness of each cluster. For example,
having hundreds of thousands of nodes show up in the same cluster at the
same point of time might cause trouble! (But, in this case, the wireless
media itself would become congested long before the ISATAP routers.)

Fred Templin
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 13 Nov 2002 14:16:32 -0800

Margaret Wasserman wrote:
> I'm not sure where the concern is coming from that we will 
> make a major change to the addressing architecture during the 
> RFC editing phase.  Neither Bob nor I have proposed or 
> advocated that course of action.

Brian's original proposal:
... unless we recall it from the RFC Editor and cycle it through the
IESG again. But I propose that we do exactly that ...

Your response:
... I would support this change. ...

Randy's response:
... if there is real consensus on this, processwise it could be done
with a note to the rfc editor or in the 48 hour edit call as s/he is
doing the final edits. ...

IMHO, that looks like a subversion of the wg process for something that
is in effect a major architectural change. 

> 
> You and I may disagree on whether or not this change is 
> warranted, and we may disagree about whether it is a major 
> architectural change or just a usage restriction, but we do 
> agree on one thing...
> 

Yes. The reason I claim it is architectural is it proscribes against
simultaneous support for multiple scopes. 

> 
> So, I would _not_ support making this change without rough WG 
> consensus and proper WG and IESG review, and I'm sure that 
> Bob wouldn't either.
> 

I am satisfied, and cautiously optimistic.
Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Nov 2002 17:22:40 -0500

> access and half are not.

yes, let's take that case.  but give them all global addresses.

assign one bit in the site's portion of the address which means
"allowed global access" half of those nodes get globals with that 
bit set, the other half globals with that bit clear.   put that 
bit anywhere in the site's portion of the address that makes it 
easy to filter the non-allowed traffic.

now apps have a global address space to work with.  they don't
have to know about network topology.  they don't have to keep
track of scopes.  they don't have to try to facilitate operation 
between sites.  

the way the app determines whether it is permitted to send 
traffic between A and B is to try to send that traffic.  
this works no matter where the decision to try to get
A and B to talk to each other is made.

if the network is set up right, an attempts by a host to
talk to a host which it's not authorized to talk to 
results in an ICMP destination unreachable - administratively 
prohibited response.

another nice thing is that there are no wired-in restrictions on 
where the security boundaries are, how many policies there are,   
etc.  you can extend this kind of policy enforcement to work between 
multiple sites if you want to work it out with them.  you can punch 
holes in it if you need to, so that under certain conditions certain 
nodes are permitted to communicate even though one of them has that 
bit set.  

perhaps most importantly - it doesn't try to use a single bit 
to communicate complex and unworkable security policies to apps.

Keith

---

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

> from the global Internet, site-locals seem like a nice feature.

Right.  But I don't know how to get arbitrary apps to work over such networks.

---

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

> rather than letting them share a hub?

who said anything about separate pieces of hardware?
we've been routing multiple subnets on the same cable for ages now.

Keith

---

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

Keith

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 14 Nov 2002 12:48:07 +0900

>>>>> On Wed, 13 Nov 2002 09:30:23 -0800, 
>>>>> Bob Hinden <[email-masked]> said:

> better to document what it is and why it isn't a good idea and move on.

I agree.  As I was afraid, we're now in the Nth time of the same loop
of discussion.

I would say, hoping this does not cause another flame, that the issues
of site-local are not crucial for the deployment of IPv6.  (The
situation is different from the case for AAAA vs A6.  At that time, we
had to pick up a particular one, or we could not go further).  We
should terminate the discussion, which will not be more constructive,
by describing the issues and pitfalls clearly, and should concentrate
on other important issues such as the ones Margaret raised the other
day.

					JINMEI, Tatuya

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Nov 2002 23:48:54 -0500

> of site-local are not crucial for the deployment of IPv6. 

I respectfully disagree.  I think it's critical that we solve this 
issue; otherwise IPv6 will not support more applications than 
NATted IPv4. 

We seem to have near-consensus on discouraging site-locals except
in a few corner cases.  It would be really unfortunate if we missed
this opportunity to remove one of IPv6's worst design flaws.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Nov 2002 10:04:27 +0100

Well, that was fun: send one message and receive a few hundred. Peace.

I'm very sensitive to the argument about intermittently connected
networks needing a stable prefix. So I would finally prefer the 
addressing architecture to contain yet another version of the
text in question:

   Site-local addresses are designed to be used for addressing inside of
   a site which is not permanently connected to the Internet. Using 
   site-local addresses, a subnet ID may be up to 54-bits long, but it 
   is recommended to use at most 16-bit subnet IDs, for convenience of
   subnet management.

Why? Because we don't have consensus, and this text carries less baggage
than the others, which seems appropriate for an architecture document.

However, it may be that this change is not enough for the WG to recall
the draft from the RFC Editor. I think we should hum on that in Atlanta.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 14 Nov 2002 08:54:32 -0500

>    is recommended to use at most 16-bit subnet IDs, for convenience of

I really don't think this is sufficient.  First because SLs don't work
for a network that has any connection to another network (it doesn't
have to be the public Internet), and second because it says nothing
at all about the problems with SLs.

I suggest

Site-local addresses are designed to be used for addressing inside of
networks which have no connections to external networks.  Other networks
need to provide global addresses to their nodes.  Use of site-local
addresses on networks with external connectivity (especially in the 
absence of global addresses) is known to cause problems for some 
applications, and such use is currently not recommended.  This recommendation
may be changed once the implications of application use of site-locals 
are better understood.  When using site-local addresses, a subnet ID may 
be up to 54-bits long, but it is recommended to use at most 16-bit subnet 
IDs, for convenience of subnet management.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 14 Nov 2002 09:32:42 -0500

Hi Keith (and others),

It isn't the purpose of the addressing architecture document to
define the full _use_ of site-local addresses.  The addressing
architecture just defines the prefix that has been assigned for
this purpose...  the full use (along with any restrictions on
that use) will be defined in the scoped addressing architecture
document.

I agree that there is a bit of wording in the addressing architecture
that may need to be changed, if we agree to some sort of restricted
usage model for site-locals.  If necessary, this wording can be
changed in the scoped addressing architecture  an "update" to
the addressing architecture.  Or we can go back and change the
addressing architecture itself once we understand the nature of the
change that we want to make.

At this point, I think that it is most important to figure out
what limitations (if any) the WG can agree (though rough consensus)
to place on the use of site-local addresses.  Then, we can figure
out the exact wording of any required changes to the addressing
architecture.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Thu, 14 Nov 2002 10:01:08 -0500

> define the full _use_ of site-local addresses. 

yes I understand that.  trying to outline the full extent to which use 
of SL addresses might be reasonable (if that's even useful or feasible) 
would certainly require a separate (and probably quite lengthy) document.

> to place on the use of site-local addresses. 

I expect we'll have to remain fairly imprecise about this because it's
very hard to outline the exact set of conditions for which SLs don't
cause much harm.  It's much easier to outline a somewhat narrower set 
of conditions for which SLs don't cause much harm.

Maybe it would help if we could first get consensus on what SLs
are good for, since there's little point in relaxing rules for use
of SLs for situations where there are not valid use cases.

I think we can agree that SLs are useful in isolated networks
and networks with intermittent connectivity and lacking stable 
prefixes.  

are there any other valid use cases?

(no, security/filtering is not a valid use case - since this is
as easily and more flexibly accomplished with globals.)

Keith

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 15 Nov 2002 02:24:20 +0900

>>>>> On Wed, 13 Nov 2002 23:48:54 -0500, 
>>>>> Keith Moore <[email-masked]> said:

> issue; otherwise IPv6 will not support more applications than 

I don't think so, but I don't think I can convince you on this point.
In order to avoid additional confusion, I'll stop here.  (And you
don't have to convince me on this.  I don't stick to the view as long
as we can really make a consensus on the site-local usage without
wasting time.)

> in a few corner cases.

I cannot be that optimistic according to the divergent discussion
we're seeing, but if we can really make a consensus, it would of
course be the best.

					JINMEI, Tatuya

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 14 Nov 2002 12:39:19 -0500

I agree that site-locals are a headache and should be carefully
considered.

However, for the purposes of the address architecture document
the new paragraph is sufficient.  It states the fundamental design
assumptions behind site-locals and that should be enough to caution
people to their use.

Stating that "more experience is needed" leads me to compare this
with flowlabel definition and really don't want to go there.

I also agree with Margarett that we shouldn't try to define the usage
of this address here.

-vlad

---

From: Richard Carlson <[email-masked]>
Date: Thu, 14 Nov 2002 12:52:24 -0600

I wouldn't at Atlanta, so I'll hum on-line.  I can accept this 
compromise.  It recommends that SL's be user in some cases, but doesn't 
prohibit future uses.

Rich

At 10:04 AM 11/14/02 +0100, Brian E Carpenter wrote:
> connected

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

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: "Fred L. Templin" <[email-masked]>
Date: Thu, 14 Nov 2002 11:51:35 -0800

There have been some alternate wording suggestions since Brian's
original message, but I like his text the best of all I've seen
and vote to adopt it as it stands.

We still have the use case of large networks that may have only
intermittent connectivity to the global Internet that will need
a stable prefix, as Brian says. But due to scaling limitations,
a flat addressing space simply won't suffice - there needs to be
some intra-site routing based on the stable prefixes. Finally, we
have to account for cases that can occur due to mobility:

  1) A large mobile network travels together from one attachment
     point to the internet to another

  2) individual nodes or clusters in a non-attached network travel
     to a different location within the same non-attached network

  3) individual nodes or clusters from one non-attached network
     travel to a differenet non-attached network

The mobile ad-hoc network case (at least) is going to require routing
based on stable prefixes on networks with only intermittent attachment.
If there are problems with the apps, as Keith suggests, we're just
going to have to fix them. I'm willing to help in any way I can.

Fred Templin
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 14 Nov 2002 16:12:22 -0500

> going to have to fix them.

I'll remind you that the purpose of the network is to support applications.

If the network doesn't do that job, there's only so much the app writers
can do to fix it.  

Pretending that it's somebody else's problem won't fly.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 14 Nov 2002 16:15:03 -0800

Brian E Carpenter wrote:
> I'm very sensitive to the argument about intermittently 
> connected networks needing a stable prefix. So I would 
> finally prefer the 
> Why? Because we don't have consensus, and this text carries 
> less baggage than the others, which seems appropriate for an 
> architecture document.
> 
> However, it may be that this change is not enough for the WG 
> to recall the draft from the RFC Editor. I think we should 
> hum on that in Atlanta.

I still believe this is a fundemental change in the architecture. In an
attempt to provide a constructive alternative, leave the architecture
document alone, then in the 'scoped' document change the definition text
to:

Site-local scope, for uniquely identifying interfaces within a single
site only. Site-local addresses are designed to provide stable addresses
for use inside a site. A "site" is, by intent, not rigorously defined
(just as Areas are not rigorously defined in an IGP), but is typically
expected to cover a region of topology that belongs to a single
organization and is located within a single geographic location, such as
an office, an office complex, or a campus. As such, one common use
instance of a site border might be the boundary between the IGP and EGP.
Use of site-local addresses for connections external to a site is
strongly discouraged, because they will usually be ambiguous values
outside their domain of reference. When applications are expected to
work across the site boundary, care should be taken to ensure all
participating nodes have global scope addresses available. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 14 Nov 2002 19:55:42 -0500

> I still believe this is a fundemental change in the architecture.

It's just clearing up an earlier misunderstanding about the architecture - 
the idea that site-locals are suitable for general-purpose use.  As such, 
it belongs at least in the addrarch document.  

Of course, clarifications in other documents are of course desirable.