Subject: Why I support deprecating SLs

From: Thomas Narten <[email-masked]>
Date: Thu, 03 Apr 2003 16:54:13 -0500

It's a shame that not everyone could be at the meeting. IMO, it was
one of those rare IETF moments in history where the room actually had
a moment of clarity and actually was mostly on the same page. And I'm
not saying this only because I personally am happy to see SL
deprecated, but because even part way into the presentation, I was
telling myself the WG is not going to be able to come to any decision
today. But the mood in the room really did seem to shift during the
discussion. I was simply stunned at the end of the meeting at the
apparent clarity and decisiveness that had been expressed in the call
for deprecated SLs. IMO, the room knew exactly what it was doing, and
was also informed about what it was doing. It was not a forced
decision.

I believe the session was broadcast on the mbone, so it must be
archived somewhere. (anyone know where?)  Anyone not at the meeting
who cares about this issue really needs to listen to that discussion
in its fullness; the minutes do not come close to capturing what
happened during the meeting.

Having said that, one of the great difficulties I have with SLs is
that I don't see a viable "compromise" or "middle ground". Every
proposal I have looked at either uses SLs in very restricted settings
(e.g, disconnected sites), or ends up having to implement the full
blown "multi-sited node" (even though try to claim otherwise). I find
scenarios that argue for a middle ground to be an unworkable illusion.

Consider a bottom line. If we say SL addresses are a reasonable thing
for (say) home networks doing autoconfig, and so on, the reality will
be that SOHO routers will find ways of creating zeroconf environments
that enable SL by default. They will then be used in practice in huge
numbers of home networks. Corporations will likewise be tempted to use
them, since they seem to provide "permanent" addresses, and
"stability" across renumbering. So, we have situation not unlike being
half-pregnant.  In practice, SLs will become widely used in many
organizations.

But, once you have wide usage in terms of independent networks
numbered using SLs, you have the inevitable problem of what happens if
a node is in two sites at the same time. I don't buy the argument that
this won't happen much and that the market can fill the gap if there
is a need (and the IETF thus won't need to do this). If widespread
useage of SL in networks becomes the reality, devices will be forced
to work in those enviornments. One simple example: at home, I have my
home network with a DSL link to the internet and also a VPN connection
to my corporate intranet. This is a *very* common operating
configuration. (Does anyone believe this won't be a common
environment?) If both the home and corporate network use SL addressing
(as they will in practice), things just won't work right unless nodes
implement the multi-sited node architecture.

Thus, I continue to come to the conclusion that we can't have it both
ways. We either deprecate SLs, or we do the full blown multi-sited
node. Doing anything in between will not work well enough in practice
(i.e., is equivalent to us putting our heads in the sand) and will
lead to interoperability problems, failed communications, and a less
robust Internet. Exactly the opposite of what I believe IPv6 is all
about.

Does deprecating SL addresses cause problems? Clearly yes. And we need
to put our engineering minds together to take those problems on as
work items and develop solutions. And in particular, better overall
solutions than we have with SLs. But I think we can do this, and we
should do this, as it will lead to a better overall long-term
technical result.

Touching on the most common reasons people seem to have for supporting
SLs:

> 	- Site-locals should be retained for disconnected sites.

1) The WG will need to take an an activity to develop a solution for
   dealing with disconnected sites. I know I'll get flamed at some
   level for this, but we need a short problem statement to understand
   the basic constraints. (like, has to work out of the box, has to
   ease the pain of merged networks, etc.) But this can be 1-2 pages
   long, I suspect, and shouldn't take a year to develop. I think we
   collectively already know the constraints, we just need to write
   them down.

   We might also list some possible solutions, just to give folk a
   warm feeling that there are resonable approaches here (others have
   already posted such approaches), and that the WG isn't just putting
   its head in the sand. Personally, I'm not worried about this
   problem because I believe we can find reasonable solutions that
   don't involve SLs. This isn't a fundamentally hard problem like,
   say, multihoming.

> 	- Site-locals should be retained for intermittently
> 		connected sites.

2) The WG will need to take on an activity to develop a solution for
   intermittantly connected sites. Again, here I'm not that
   worried. For example, we have a lot of IPv6 addresses. There is no
   reason from a technical perspective why intermittantly disconnected
   sites can't continue using a prefix from its ISP after it is
   disconnected. IMO, there is something fundamentally broken with the
   idea that ISPs will be giving intermittantly connected sites
   different /48s or /64s each time they reconnect. 

   But in any case, there are again other approaches as well, e.g.,
   those also developed in 1) above would apply here to. So, again I
   do not think this is an unsolvable problem and am comfortable with
   the idea that we can and will solve it.

> 	- Site-locals should be retained for their access control
> 		benefits.

3) The WG should continue exploring the simple site boundary security
   approaches (e.g., zill/smb drafts). It's less clear to me
   (personally) how well this work will pan out, but it's definitely
   worth exploring. Besides, there isn't really agreement that SLs
   provide a good security boundary model anyway, so it isn't clear
   that SLs are an obvious answer here.

> 	- Site-locals should be retained as a means for internal
> 		connections to survive global prefix renumbering.

4) This is strikes me as a nice requirement, but something we don't
   have a solution for, even with SLs. We need to accept that we have
   no solution and SL is doesn't really seem to be a help here. Or, if
   folk really think there is an approach, its high time we had an ID
   to look at that actually fleshed out the details. We've had
   attempts in the past, but they have been abandoned.

Thus, in summary, I support the deprecation of SLs with the
understanding that taking this step will require that we take on some
additional work items. But I don't see lack of specific solutions to
those work items today as being a reason to delay deprecating SLs.

Thomas
--------------------------------------------------------------------
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: "James Kempf" <[email-masked]>
Date: Thu, 3 Apr 2003 14:35:22 -0800

Thomas,

I agree with your opinion and also support deprecating site locals. The
discussion you posted is clear and very persuasive.

However, I believe some of the resistance to deprecation may be the result of
people who have implementations and would rather not have to pay the costs of
ripping out that code and putting in something new. The logic here is the
following: IETF may make the decision to deprecate, but it is the individual
vendors that have to bear the cost of deprecation. If this is a widespread
concern (and I may be misinterpreting so it may not be), then I'd ask those with
this very practical concern to consider the alternative costs associated with
deployment problems that Thomas has outlined in the note below. The customer
service costs could easily dwarf the engineering costs of removing site locals,
should these deployment problems occur in practice.

            jak

----- Original Message -----
From: "Thomas Narten" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 03, 2003 1:54 PM
Subject: Why I support deprecating SLs

...

---

From: Thomas Narten <[email-masked]>
Date: Thu, 03 Apr 2003 20:39:28 -0500

Hi James.

> However, I believe some of the resistance to deprecation may be the
> result of people who have implementations and would rather not have
> to pay the costs of ripping out that code and putting in something
> new.

This I don't understand. AFAIK, there is little or no code to rip
out. And if the code is there, but no site-locals are actually
configured or assigned to nodes, any code related to site-locals
doesn't get executed and is harmless. So I don't see what problem
there is with deprecating them with regards to existing
implementations. I don't imagine anyone is going to say we need to put
wording in some spec that makes existing implementations that have
code related to site-locals be declared non-conformant. That would be
silly.

Do folks think this above is a significant issue?

Thomas

---

From: John Bartas <[email-masked]>
Date: Thu, 03 Apr 2003 19:29:48 -0800

Hi Thomas,

> Do folks think this above is a significant issue?

	I just finished writing & documenting a v6 stack for embedded systems.
My employer will be selling it as C source code, along with technical
manuals explaining how to port the code. My experience is that many of
our customers will go through every source file and structure in an
effort to understand all the details of what they are preparing to field
and support. 

	I currently have a site-local address field in my interface structure,
right alongside link-local and global addresses. There's also a few
paragraphs in the manual explaining why the field is there and how it is
initialized. If site local addresses disappear from the RFCs, I know
from experience that I'll have customers calling our support team and
asking what these fields are and how they should be initialized. 

	If the vote is to deprecate these addresses, we (my employer) will take
a hit even if we delete these fields from the sources and documents the
same day the RFC is blessed. There will always be some customers using
the older RFCs, or testing against older v6 implementations, and they'll
want to know where the site-local support is. 

	This issue is not big enough that anyone should brain damage IPv6 over
it, but it's actually part of a larger issue - the credibility of IPv6.
If this WG decides that site-local addresses really serve no purpose
after specifying them since 1995, it will not give the developers and
users of the world warm fuzzies about the stability of IPv6. This debate
has already generated amusement and cynicism among my v4-only
co-workers. 

	 I have not voted yet, since there's good reasons on both sides; and
I've never had the experience of renumbering or merging a large IPv6
network. What I'd really like to see is site locals left in the spec,
but issue a recommendation that they be avoided, by both developers and
users, until their use is better understood.

	Sorry to bore you with my personal problems, by you asked :-)

-JB-

-- 
-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: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Apr 2003 22:40:03 -0500

>What I'd really like to see is site locals left in the spec,

This is actually a pretty good match for "deprecation" by
my definition.  We'd keep the prefix in the spec, but mark
it as "deprecated, do not use", or something like that.

I think that we all understand that we can just eliminate
this prefix from the specification and re-use it for something
later (or at least not any time soon), as there are some
implementations that treat these addresses specially.

But, we can deprecate the prefix and indicate that it shouldn't
be used.

Margaret

---

From: Brian Haberman <[email-masked]>
Date: Fri, 04 Apr 2003 09:11:53 -0500

> Do folks think this above is a significant issue?

So, as most of you probably know, I have implemented a router that
supports scoped addresses (unicast and multicast).  If I still
supported that box, I would be quite happy to rip the support out.

If someone wants to see a presentation on what I did, go find the
proceedings from the routing area meeting in Atlanta.

I can see where implementations like John Bartas' could have
support issues when customers can't align code with RFCs.  But,
I would rather deal with that scenario than trying to debug
operational problems with site locals.

I would like to hear from other people who have actually implemented
SL support, and I mean ALL of the support (routing/forwarding, apps,
dns, firewalls, mobility, etc.).

Regards,
Brian