Subject: RE: site-locals

From: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Apr 2003 08:17:56 -0500

Hi John,

>What is the amount of work to depreciate site locals - how many RFCs need
>to be updated? I'm not convinced that deprecating site locals really solves
>anything.

The work to keep, and finish, site-locals is much greater than
the work to deprecate them.

To deprecate them, I think that the addressing architecture
and the default address selection rules would be the only RFCs
(both at PS) that we need to change.

To keep them, we need to document and resolve the issues that
they cause, update all of the IPv6 routing protocols to
document how site-boundaries are maintained, and document
how address selection will be performed in several upper
layer protocols (at least SCTP, SIP and FTP).  We might also
need to provide guidance to non-IETF applications protocol
developers and/or application developers for how to handle
site-local addresses in non-IETF applications.  And, we'd need
to specify split DNS.

Margaret

--------------------------------------------------------------------
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: Leif Johansson <[email-masked]>
Date: Thu, 03 Apr 2003 14:45:59 +0200

> site-local addresses in non-IETF applications.  And, we'd need
This is assuming that it is possible to "live with" site-locals. We may
wind up writing lots of documents that essentially say "lots of apps will
break; tough luck!".

I propose that site-locals change so many fundamental assumptions that
applications make that the IAB need to study the issue and make a
recommendation -- i.e I don't think that the inclusion of site-locals in
the core architecture of the Internet should be at the sole discression of
the ipv6 or any other wg.

       Leif

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 3 Apr 2003 10:04:37 -0800

Margaret Wasserman wrote:
> ...
> The work to keep, and finish, site-locals is much greater 
> than the work to deprecate them.

Wishful thinking...

> and the default address selection rules would be the only 
> RFCs (both at PS) that we need to change.

What about all the documents that need to be created to address the real
requirements of network managers? Deliver on those, then it will be time
to talk about a couple of wording changes in current documents.

> document how site-boundaries are maintained, and document how 
> address selection will be performed in several upper layer 
> protocols (at least SCTP, SIP and FTP).  We might also need 
> to provide guidance to non-IETF applications protocol 
> site-local addresses in non-IETF applications.  And, we'd 
> need to specify split DNS.

Almost all of that will need to happen regardless of the prefix used,
because the architectural reality of the Internet is that many of the
attached networks also have a private use space. Claiming otherwise by
simply removing a well-known tag is an irresponsible act.

This whole deprecate effort is about making it someone else's problem.
The IETF has successfully driven out most of the network managers, and
now the remaining developers are trying to dictate how networks get run
by removing the tools that people really use. The false sense of
accomplishment here will only result in mass chaos as network managers
continue to run the networks the way they want, but are forced to use
ad-hoc approaches to do so.

Tony

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 04 Apr 2003 09:03:14 +0200

> This whole deprecate effort is about making it someone else's problem.

It is less of a problem to do the right thing, as Elliot wrote. Less pain
now, less pain in the future. 

> by removing the tools that people really use. 

You are right in the sense that there are too few operations people in the
IETF standards work. And yes, the problem is that the remaining developers
are inventing things we as operators (I help run a number of smallish
research nets, only OC-192 lines and perhaps 2-300000 users, not much to
talk about, but I think I count as "operator".) do not want. 

Your analysis and argument fails on the pivotal point, though: 

We do not want ambigious addresses. The only reason to do that is were
there lack of address space. Really. 

We do not want NAT. Nat breaks things. Not for web surfing, but most other
things require hacking, be it Kerberos tickets without address info or what
have you. 

We do not want unreachability built-in. We can do that ourselves, or by
means of backhoe. 

We do not want to break DNS. It is in a enough sad state as it is. 

I am talking to a lot of friends in the operations community these days, to
make them aware of this consensus call, and have them say their meaning.
Without exception their assessment of SL can be summarised to "OUTRAGEOUSLY
UGLY". 

So, I'm glad that you call on the operator community, but I think you will
be surprised at what they say. 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 4 Apr 2003 10:26:50 +0300 (EEST)

> > by removing the tools that people really use. 
[...]
> be surprised at what they say. 

I support you all the way, but in all fairness, there is likely a huge
disconnect between "operators who are doing the right thing" (I hope I am
at least: we don't do any NAT etc.) and "operators who like doing the
wrong thing" or "operators who are forced to doing the wrong thing for
whatever reasons".  (It is not useful to use the words "right" and "wrong"  
about NAT's and what have you here but I use them for simplicity and
brevity.)

So, in a sense it would also be good to get feedback from ops folk of the
latter categories.  Those do exist, but I assume *they* are ones that are 
more rarely seen at the IETF (but also probably those who do not heed what 
IETF says in any case).

But regardless, it's still the question of doing it right rather than
"doing it the IPv4 way".

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 04 Apr 2003 09:37:18 +0200

--On Friday, April 04, 2003 10:26:50 +0300 Pekka Savola <[email-masked]>
wrote:

> more rarely seen at the IETF (but also probably those who do not heed
> what  IETF says in any case).
> 

Yes, that would be desirable, but perhaps hard to attain, both in terms of
participion and compliance. 

Most "outside-ipng-people" I've spoken to lately immediately associate SL
with RFC1918 and v4-NAT, in a conceptual way. They are in many cases using
both these techniques, but only because it is not feasible for them to get
address space enough for their networks. It is probably safe to say that
this restriction will go away in v6.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 4 Apr 2003 09:25:27 -0800

Måns Nilsson wrote:
> ...
> So, I'm glad that you call on the operator community, but I 
> think you will be surprised at what they say. 

I am not surprised because ISPs have a different perspective on this
issue (and many others) than enterprise network managers. The network
managers that will primarily use SL are at the edge, because the ISP has
a mechanism to acquire prefixes at will. Claiming that ISPs see no need
has almost as much value as the application developer that is looking to
avoid a little extra work. Until we provide the edge network manager
with viable alternatives, we have to keep the tool they can use.

Tony