Subject: CONSENSUS CALL: Deprecating Site-Local Addressing

From: Margaret Wasserman <[email-masked]>
Date: Tue, 01 Apr 2003 14:37:56 -0500

Hi All,

At the IPv6 WG meetings in SF, we reached consensus on several
points, all of which will be confirmed on the IPv6 mailing list.
One point in particular seems to be the source of discussion
on our list and elsewhere, so we will check this consensus on the
mailing list now.  Specifically, we would like to check the consensus
of the IPv6 WG regarding the deprecation of site-local addresses.

This email asks those that were NOT present at the Thursday IPv6
meeting in SF to express their opinions on a question that was
asked of the room.   If you expressed an opinion on this issue in
SF you can skip this message; in any case you MUST NOT respond to
this query.

By now, all of you have heard about the IPv6 meeting held on
Thursday, March 20th, where we discussed what to do about
IPv6 site-local addressing.

At the meeting, the chairs (Bob Hinden and Margaret Wasserman)
changed the agenda to include a joint presentation by the
chairs on various options for site-local usage.  There were
no objections to the agenda change.

The chairs' joint presentation can be found at:

http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt

After the chairs' joint presentation, there was over an hour of
lively discussion that covered many aspects of site-local
addressing.  Draft minutes of the discussion can be found at:

http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt

These minutes are a summary of the discussion, and they did
not capture every detail of the discussion.

During the discussion, it became clear that the "exclusive" model
proposed by the chairs had some fundamental flaws and was not
a viable option.  The WG was unwilling to choose between the three
options presented for site-local usage ("limited", "exclusive" or
"moderate"), believing that all three models represented a poor
cost vs. benefit trade-off.  And, as the discussion developed, it
became clear that there was growing support for deprecating
site-local addressing.

After the usual discussion regarding the phrasing and meaning
of the question (not all of which was captured in the minutes),
the chairs asked a yes/no question:  "Should we deprecate IPv6
site-local unicast addressing?"  There was clear consensus in the
room to deprecate site-local addressing.  So, now it is time to
check that consensus on the mailing list.

In order to get a good read for consensus on this point, PLEASE
adhere to the following rules:

NOTE:  DO NOT reply if you already expressed an opinion during
the IPv6 WG meeting in SF!

	- Make your response very clear (YES or NO).
        - Respond by Monday, April 7th, 2003 at 5pm EST.
        - Do NOT respond if you were physically present
		in SF and participated in the consensus
		call at that time (We are trusting you!).
        - Respond to this thread with the subject intact.
        - Respond only once.
	- Clearly identify yourself (in the From: line or
		inside your message).
	- Include the IPv6 WG mailing list in your response
		([email-masked]).
        - PLEASE do NOT start any discussion in this thread
                (Discussions are encouraged in other threads).

Any responses that do not adhere to these rules may not be counted.

The question is:

         Should we deprecate IPv6 site-local unicast addressing?

Valid responses are:

	"YES -- Deprecate site-local unicast addressing".
	"NO -- Do not deprecate site-local unicast addressing".

If you express an opinion not to deprecate site-local addressing, it
would be helpful if you would provide a reason.  Providing a reason
is completely optional, but it may help us to determine how to move
forward if the consensus to deprecate site-locals does not hold.
Possible reasons include:

	- Site-locals should be retained for disconnected sites.
	- Site-locals should be retained for intermittently
		connected sites.
	- Site-locals should be retained for their access control
		benefits.
	- Site-locals should be retained as a means for internal
		connections to survive global prefix renumbering.
	- Other (please specify).

Please, make your response _very_ clear (either YES or NO), or it will
not be counted.

Please Note:  DO NOT respond if you already participated in the
consensus call at the meeting in SF.  At the meeting, there were
102 people who raised their hands for YES (deprecate site-locals)
and 20 people who raised their hands for NO (do not deprecate
site-locals).  We will add the responses received on the mailing
list to the hands counted at the meeting, and use that information
to determine full WG consensus on this issue.

If you feel an urgent need to reply to something that someone sends
in response to this message, please do it in a SEPARATE THREAD with
a different subject line.  No discussion in this thread!

Please voice your opinion on this important issue.

Bob Hinden & Margaret Wasserman
IPv6 WG Chairs

--------------------------------------------------------------------
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: Ralph Droms <[email-masked]>
Date: Tue, 01 Apr 2003 14:55:11 -0500

Margaret,

Sorry to ask a question for which the answer might be obvious...

You wrote:

>the IPv6 WG meeting in SF!

Does "expressed an opinion" mean "stepped to the mike and
spoke" or "raised your hand during the consensus determination
at the meeting"?

- Ralph

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 1 Apr 2003 12:10:53 -0800

YES -- Deprecate site-local unicast addressing

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 01 Apr 2003 15:00:57 -0500

>spoke" or "raised your hand during the consensus determination

The latter.  Do not respond to this consensus call if you
already raised your hand at the meeting in SF.  People who
spoke at the mike, but did not express an opinion during
the show of hands, may express their YES/NO opinion now
on the list.

Thanks, Ralph.

Margaret

---

From: Markku Savela <[email-masked]>
Date: Tue, 1 Apr 2003 23:17:04 +0300

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

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

- Site-locals should be retained as a means for internal connections
  to survive global prefix renumbering.
--------------------------------------------------------------------
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, 1 Apr 2003 12:15:28 -0800

NO -- Do not deprecate site-local unicast addressing

	- Site-locals should be retained for disconnected sites.
	Easy to get     
   No public registration, payment, customer/provider relationship, or 
   approval required.

 	- Site-locals should be retained for intermittently
 		connected sites.
 	- Site-locals should be retained as a means for internal
 		connections to survive global prefix renumbering.
	Stable     
   Both during ISP changes, and for intermittently connected networks. 

 	- Site-locals should be retained for their access control
 		benefits.
	Private      
   Well-known routing filter provides multiple levels of filtering to 
   ensure a single error does not expose the network to global access. 

Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Margaret 
> Wasserman
> Sent: Tuesday, April 01, 2003 11:38 AM
> To: [email-masked]
> Subject: CONSENSUS CALL: Deprecating Site-Local Addressing
> 
> 
> 
> Hi All,
> 
> At the IPv6 WG meetings in SF, we reached consensus on 
> several points, all of which will be confirmed on the IPv6 
> mailing list. One point in particular seems to be the source 
> of discussion on our list and elsewhere, so we will check 
> this consensus on the mailing list now.  Specifically, we 
> would like to check the consensus of the IPv6 WG regarding 
> the deprecation of site-local addresses.
> 
> This email asks those that were NOT present at the Thursday 
> IPv6 meeting in SF to express their opinions on a question that was
> SF you can skip this message; in any case you MUST NOT 
> respond to this query.
> 
> At the meeting, the chairs (Bob Hinden and Margaret 
> Wasserman) changed the agenda to include a joint presentation 
> by the chairs on various options for site-local usage.  There 
> were no objections to the agenda change.
> 
> After the chairs' joint presentation, there was over an hour 
> of lively discussion that covered many aspects of site-local 
> During the discussion, it became clear that the "exclusive" 
> model proposed by the chairs had some fundamental flaws and 
> was not a viable option.  The WG was unwilling to choose 
> between the three options presented for site-local usage 
> ("limited", "exclusive" or "moderate"), believing that all 
> three models represented a poor cost vs. benefit trade-off.  
> And, as the discussion developed, it became clear that there 
> was growing support for deprecating site-local addressing.
> 
> of the question (not all of which was captured in the 
> minutes), the chairs asked a yes/no question:  "Should we 
> deprecate IPv6 site-local unicast addressing?"  There was 
> clear consensus in the room to deprecate site-local 
> addressing.  So, now it is time to check that consensus on 
> the mailing list.
> 
> In order to get a good read for consensus on this point, 
> PLEASE adhere to the following rules:
> 
> NOTE:  DO NOT reply if you already expressed an opinion 
> during the IPv6 WG meeting in SF!
> 
> If you express an opinion not to deprecate site-local 
> addressing, it would be helpful if you would provide a 
> reason.  Providing a reason is completely optional, but it 
> may help us to determine how to move forward if the consensus 
> to deprecate site-locals does not hold. Possible reasons include:
> 
> Please, make your response _very_ clear (either YES or NO), 
> or it will not be counted.
> 
> Please Note:  DO NOT respond if you already participated in 
> the consensus call at the meeting in SF.  At the meeting, 
> there were 102 people who raised their hands for YES 
> (deprecate site-locals) and 20 people who raised their hands 
> for NO (do not deprecate site-locals).  We will add the 
> responses received on the mailing list to the hands counted 
> at the meeting, and use that information to determine full WG 
> consensus on this issue.
> 
> If you feel an urgent need to reply to something that someone 
> sends in response to this message, please do it in a SEPARATE 
> THREAD with a different subject line.  No discussion in this thread!
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 01 Apr 2003 12:16:34 -0800

Short answer:

SLs need to be deprecated in favor of better tooling.
SLs as currently envisioned eliminate justification to move to IPv6. 
Applications won't know how to make a proper choice.
Encourages behavior that breaks connectivity.

Eliot

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 01 Apr 2003 15:27:46 -0500

Does not provide any tangible security benefit.
	Provides false sense of security.
	Increases application complexity.
	Reduces application reliability.
	Requires too many compensating hacks to other protocols.

---

From: Mark Thompson <[email-masked]>
Date: Tue, 1 Apr 2003 21:34:44 +0100

"NO -- Do not deprecate site-local unicast addressing"
 
 	- SLs should be retained for disconnected sites

 	- SLs should be retained for intermittently connected sites

	- Applications should NOT be aware (or need to be aware) 
	of any difference between site-local and any other address 
	(c.f. anycast); a principal purpose of SLs should be for
	nodes having site-local access to site-local services, 
	irrespective of the number (0+) of external links to 
	other networks, ephemeral or otherwise. Any requirements,
	e.g., for split-view DNSes is not this WG's concern

 	- SLs should NOT be retained for their access control
	benefits and it SHOULD be clearly documented that this
	is a broken philosophy!

Mark Thompson,
University of Southampton, UK

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 1 Apr 2003 23:39:42 +0300

Eric Klein -  No we should not deprecate IPv6 site-local unicast addressing

---

From: "Qing Li" <[email-masked]>
Date: Tue, 1 Apr 2003 12:45:12 -0800

--  Qing Li
          [email-masked]

---

From: Lars Erik Gullerud <[email-masked]>
Date: 01 Apr 2003 23:09:24 +0200

---

From: Mike Saywell <[email-masked]>
Date: Tue, 1 Apr 2003 22:17:15 +0100

NO -- Do not deprecate site-local unicast addressing.

	- Other #1
	  In the absence of a defined private prefix people will either
	  invent their own or use 2002::/16 with RFC1918 addresses which
	  will cause worse problems than SLs.

	- Other #2
	  SLs should be retained since they provide a large and free
	  address space for anybody to use, test, research and develop
	  with.

--
Mike Saywell
Southampton University, UK.

---

From: Steven Blake <[email-masked]>
Date: 01 Apr 2003 16:36:14 -0500

> 	"NO -- Do not deprecate site-local unicast addressing".

I think the question needs to be more specific:

- Deprecate addresses in fec0::/48?

- Deprecate addresses in fec0::/10 (with no scheme to make bits 10:47
  probabilistically or globally unique at a site)?

- Deprecate all non-PA, non-link-local unicast addresses?

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                +1 919-472-9913

---

From: Michael Thomas <[email-masked]>
Date: Tue, 1 Apr 2003 13:38:00 -0800 (PST)

Yes, nuke site locals.

	  Mike

---

From: Richard Carlson <[email-masked]>
Date: Tue, 01 Apr 2003 15:42:10 -0600

Institutions and individuals should be able to obtain private non-Internet 
IP addresses in a cheap, easy fashion.  No other address space is defined 
to meet these objectives.

Rich

[snip snip snip]

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

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: "Shannon McFarland \(shmcfarl\)" <[email-masked]>
Date: Tue, 1 Apr 2003 14:56:17 -0700

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Margaret Wasserman
Sent: Tuesday, April 01, 2003 12:38 PM
To: [email-masked]
Subject: CONSENSUS CALL: Deprecating Site-Local Addressing

Hi All,

At the IPv6 WG meetings in SF, we reached consensus on several points,
all of which will be confirmed on the IPv6 mailing list. One point in
particular seems to be the source of discussion on our list and
elsewhere, so we will check this consensus on the mailing list now.
Specifically, we would like to check the consensus of the IPv6 WG
regarding the deprecation of site-local addresses.

This email asks those that were NOT present at the Thursday IPv6 meeting
in SF to express their opinions on a question that was
asked of the room.   If you expressed an opinion on this issue in
SF you can skip this message; in any case you MUST NOT respond to this
query.

By now, all of you have heard about the IPv6 meeting held on Thursday,
March 20th, where we discussed what to do about IPv6 site-local
addressing.

At the meeting, the chairs (Bob Hinden and Margaret Wasserman) changed
the agenda to include a joint presentation by the chairs on various
options for site-local usage.  There were no objections to the agenda
change.

After the chairs' joint presentation, there was over an hour of lively
discussion that covered many aspects of site-local addressing.  Draft
minutes of the discussion can be found at:

During the discussion, it became clear that the "exclusive" model
proposed by the chairs had some fundamental flaws and was not a viable
option.  The WG was unwilling to choose between the three options
presented for site-local usage ("limited", "exclusive" or "moderate"),
believing that all three models represented a poor cost vs. benefit
trade-off.  And, as the discussion developed, it became clear that there
was growing support for deprecating site-local addressing.

After the usual discussion regarding the phrasing and meaning of the
question (not all of which was captured in the minutes), the chairs
asked a yes/no question:  "Should we deprecate IPv6 site-local unicast
addressing?"  There was clear consensus in the room to deprecate
site-local addressing.  So, now it is time to check that consensus on
the mailing list.

In order to get a good read for consensus on this point, PLEASE adhere
to the following rules:

NOTE:  DO NOT reply if you already expressed an opinion during the IPv6
WG meeting in SF!

The question is:

Valid responses are:

If you express an opinion not to deprecate site-local addressing, it
would be helpful if you would provide a reason.  Providing a reason is
completely optional, but it may help us to determine how to move forward
if the consensus to deprecate site-locals does not hold. Possible
reasons include:

Please Note:  DO NOT respond if you already participated in the
consensus call at the meeting in SF.  At the meeting, there were 102
people who raised their hands for YES (deprecate site-locals) and 20
people who raised their hands for NO (do not deprecate site-locals).  We
will add the responses received on the mailing list to the hands counted
at the meeting, and use that information to determine full WG consensus
on this issue.

If you feel an urgent need to reply to something that someone sends in
response to this message, please do it in a SEPARATE THREAD with a
different subject line.  No discussion in this thread!

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 1 Apr 2003 23:59:34 +0200

---

From: Andrew L Hazeltine <[email-masked]>
Date: Tue, 01 Apr 2003 17:20:47 -0500

Andy Hazeltine
Advanced Systems Consulting, Inc.

---

From: Shannon -jj Behrens <[email-masked]>
Date: Tue, 1 Apr 2003 14:56:16 -0800

-jj

-- 
Hacker is to software engineer as 
Climbing Mt. Everest is to building a Denny's there.
--------------------------------------------------------------------
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: George Gross <[email-masked]>
Date: Tue, 1 Apr 2003 16:27:15 -0500 (EST)

---

From: Ross Finlayson <[email-masked]>
Date: Tue, 01 Apr 2003 16:01:21 -0800

YES -- Deprecate site-local unicast addressing".

(Any benefits are vastly outweighed by the added complications, IMHO.)

	Ross.

---

From: Hiroki Ishibashi <[email-masked]>
Date: Wed, 02 Apr 2003 10:22:46 +0900

Hiroki Ishibashi

---

From: <[email-masked]> (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)
Date: Wed, 02 Apr 2003 10:42:17 +0900 (JST)

---
Tomohiro Fujisaki

---

From: Takeshi Kusune <[email-masked]>
Date: Wed, 02 Apr 2003 10:42:26 +0900

Reasons:

 (other)
 - Site-locals should be retained to stop domain hi-jack for the
   reason above.
 - Site-locals should be retained for 

Comments:
   I want only private address space like RFC1918 in IPv4.
   Any other complicated feature is not needed.
--
Takeshi Kusune <[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: SUZUKI Shinsuke <[email-masked]>
Date: Wed, 02 Apr 2003 11:44:46 +0900

"YES -- Deprecate site-local unicast addressing"

---

From: Nobuo OKABE <[email-masked]>
Date: Wed, 02 Apr 2003 12:22:05 +0900 (JST)

---- nobuo

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 02 Apr 2003 14:36:19 +0900

Before responding to the consensus call on site-local addresses, I'd
like to ask one question for clarification.  (As required, I changed
the subject line).

What was the consensus, if any, on alternatives to site-locals when SL
is deprecated?  In particular, which prefixes will we use for
disconnected or intermittently connected "site"s?  I've checked the
chair's presentation slides and the draft minutes, and (roughly)
followed the very recent discussion in the ML, but I cannot be sure
about it.

According to the draft minutes, someone mentioned we can use arbitrary
prefixes for those purposes.  That's true, but we cannot assure the
uniqueness of the arbitrary-chosen prefixes, so I don't see any
essential advantage over the existing fec0::/10 (with eliminating the
"full" usage).

I can live without site-locals, and, furthermore, I personally want
the wg to stop the endless discussion and to concentrate on more
important -from my personal perspective- issues.  So, even if the
idea of "arbitrary-chosen prefixes" is just a compromise (without any
real benefit) to convince ourselves, it's okay for me.  Then I'll vote
for deprecating site-local.

Could someone clarify this point, please?

					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: [email-masked]
Date: Wed, 02 Apr 2003 16:05:08 +1000

> followed the very recent discussion in the ML, but I cannot be sure

	The concensus call was predicated on "we will find another way
	to deal with disconnected / intermittently connected site."

	The was no concensus on how this would be achieved but there wa
	a commitment to find a solution if site-locals were deprecated.

	There are plenty of potential ways to achieve this some of
	which include:
	* get a prefix for disconnected access from a ISP.
	* set up registries.

	Mark

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [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: Hiroki Ishibashi <[email-masked]>
Date: Wed, 02 Apr 2003 15:28:35 +0900

>	* get a prefix for disconnected access from a ISP.

These will definitely increase the cost of owning even disconnected
IPv6 networks.

Hiroki Ishibashi

---

From: [email-masked]
Date: Wed, 02 Apr 2003 17:10:46 +1000

> These will definitely increase the cost of owning even disconnected

	TNSTAAFL

	RFC 1918 addresses cost real money to support.  There are
	sacrificial machines that just serve reverse lookups for
	these addresses.  They actually receive more traffic than
	the root servers.

	Site-locals will cost real money.  The address will leak.

	Put the costs of supporting disconnected / intermittently
	connected sites back on the sites that need this fuctionality.
	Having to lease a prefix will help cover the costs of
	supporting the reverse lookups on leaked lookups.

	Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Apr 2003 09:55:20 +0200

JINMEI Tatuya / 神明達哉 wrote:
> is deprecated?  

As I've already said, I think that is the wrong order of discussion.

I think we should clear the desktop first, by getting rid of ambiguous
site-local address space, and then discuss possible new solutions.

We've been going round in circles for months, and we need to stop that.

   Brian

---

From: "Fredrik Nyman" <[email-masked]>
Date: Wed, 2 Apr 2003 10:20:43 +0200

-- 
Fredrik Nyman
PacketFront Sweden AB
http://www.packetfront.com/

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Apr 2003 10:41:21 +0200

As I already said under another subject line,
what I understood we were deprecating is SL as defined
in the current address architecture, i.e. FEC0::/10.

That's the only formal definition of SL, so I don't see
what else we could be referring to.

   Brian

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 2 Apr 2003 11:36:38 +0200 (CEST)

> for deprecating site-local.

I don't think the WG has discussed the details of how to handle
disconnected sites. 

One of my high bits expressed at the mike in SF was that we should
design IPv6 for the global Internet and not add a bunch of special cases
to the global architecture to support local communication.

For local communication I personally think that just making up a prefix
might not be a bad approach. Whether you use a designed non-unique prefix
(like fec0) or a made up prefix for a disconnected site you have the same
issue; when you actually connect - either to the global Internet or to some
other local domain - you need to renumber. In the case of the global
Internet you need to renumber to make global communication work. In case
of connecting to some other local domain you need to renumber so that the
two domains can communicate i.e. they can't have conflicting addresses.
A designated non-unique prefix doesn't make this any easier.

But as I said, this is yet to be discussed in the WG, as is
the issue of bellovin/zill prefix advertisements for designating the
address prefixes for the local domain (which has most of the same
issues as using site-locals for "security" benefits).

  Erik

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 2 Apr 2003 13:02:35 +0200

[email-masked] wrote:

> > Hiroki Ishibashi wrote:

<SNIP>

> 	these addresses.  They actually receive more traffic than

Fortunatly AS112 now catches these at some IX'es thus
lowering *transit* traffic.

> 	supporting the reverse lookups on leaked lookups.

If someone doesn't want/like this they can pick a random number
and use that, they still have to renumber when they interconnect
to another site or the internet.

Greets,
 Jeroen

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Wed, 02 Apr 2003 20:44:44 +0900 (JST)

But, some mechanisms (or manner) for disconnected sites should be
invented.

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[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: Markku Savela <[email-masked]>
Date: Wed, 2 Apr 2003 15:08:38 +0300

> From: "Jeroen Massar" <[email-masked]>
> 

No, when you interconnect, you just keep using your global addresses
in parallel with site locals.

Despite claims of opposite, this combination works just fine.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 2 Apr 2003 14:21:24 +0200

> Despite claims of opposite, this combination works just fine.

Example.com: fec0::/10
Example.org: fec0::/10

Good luck in tossing the bits around to routers in between those sites
:)
Not even speaking about when you have internal webservers:

www.example.com fec0::1
www.example.org fec0::1

Even NAT won't help you here...
Or is it suddenly 'allowed' to use the global address ?
Then where did you need those site locals for again?

What you need is a globally unique /48 that is disconnected
and which one should be able to register 'cheaply'. Eg
an annual fee of E20 or something just to make sure that
not everybody starts harvesting them. The /32 from which
these /48's come (or fec0::/10 could be a great candidate)
should never be routable/announced onto the internet.

Greets,
 Jeroen

---

From: Markku Savela <[email-masked]>
Date: Wed, 2 Apr 2003 16:17:32 +0300

> Good luck in tossing the bits around to routers in between those sites

That would happen only if both sites merged into single site. If sites
are just connected via global internet

 example.com               example.org
         |
Site-A --|                |
         |---- INTERNET---|
                          |-- Site-B

If a host at example.com resolves xxx.example.org, it will not get
fec0::/10 address as reply. It will get some global address of site-B.

Yes, you need two-faced DNS, but again, this is standard practise
today. Banning sitelocals will not kill two-faced DNS.

However, a "merger", without global addresses and renumbering, would
look as

 example.com   example.org
         |
Site-A --|       |
         |--GW---|
                 |-- Site-B

Now, if site-A and site-b previously used different prefixes, like
"fec0:site:aaaa" and "fec0:site:bbbb", then merger is trivial (GUPI,
anyone?)

However, if they used overlapping fec0:: prefixes, yes, simplest would
be to renumber one of the sites.

[Although, I could also make it work with overlapping addresses as is,
but it does require a revision to the way name resolving is done--I
have this implemented, but I would not expect everyone to do it. The
solution does get a bit too complex to explain here. The solution is
designed to handle multiple overlapping IPv4 private address spaces,
so IPv6 sitelocal would be a no-brainer for it :-].

> Not even speaking about when you have internal webservers:

Well, unless sites are truly merged, accessing "internal" servers from
another site is not supposed to happen anyway.

> not everybody starts harvesting them.

Why should I pay anything? I have a small net at home with few hosts,
but connected to the internet. I just pick some random address, for
example starting with "fec0:/10".. :-).

Big organisations do not need IPv6 at all. Their internal networks run
quite happily using IPv4 private address spaces. As I said earlier,
system admins wont allow globally routable addresses for the internal
nodes anyway.

IPv6 is needed by millions of private homes getting connected to the
internet and needing global addresses. And, it is needed by millions
of mobile phones that want to run E2E applications, which need global
addresses.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 2 Apr 2003 15:37:25 +0200

> fec0::/10 address as reply. It will get some global address of site-B.

Global addresses, good, and where did you need a SL for again?

> today. Banning sitelocals will not kill two-faced DNS.

They used to walk from europe to isreal for the crusades?
Do you really think that current armies will walk all that way?
Times change, so does the internet.

Also why should 'banning' sitelocals 'kill' two-faced DNS?
Two faced DNS is just a way of showing a specific namespace
to a specific set of clients. Or for some people security
through obscurity.

> "fec0:site:aaaa" and "fec0:site:bbbb", then merger is trivial (GUPI,

And SL hasn't got any GUPI or unique addresses in it's current form.
Thats why the *current* form should be deprecated and a better way
for solving this kind of problem should be found out.
 
> be to renumber one of the sites.

Have fun renumbering ;)

> so IPv6 sitelocal would be a no-brainer for it :-].

Which breaks end-to-end connectivity. Where did you need SL for again?

> another site is not supposed to happen anyway.

Then why merge in the first place?

> example starting with "fec0:/10".. :-).

Indeed 'just pick some random address' if you don't want to
be connected to the rest of the world. No need for SL.
Also E20 or a similar amount is peanuts compared to what it
would cost if you need to renumber your complete site.

> system admins wont allow globally routable addresses for the internal

Great, if they don't need IPv6, where did we need SL for again?

> of mobile phones that want to run E2E applications, which need global

Indeed global addresses. Where did the need for SL go again?

Still no reason for keeping SL's...

Greets,
 Jeroen

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 2 Apr 2003 15:39:05 +0200

- kurtis -

---

From: Markku Savela <[email-masked]>
Date: Wed, 2 Apr 2003 16:48:54 +0300

> Global addresses, good, and where did you need a SL for again?

Well, just for fun, I keep using SL for internal connections. One
never knows when my global connection may break or change prefix, at a
whim of ISP. Or maybe I have two ISP connections, one is cheaper
during day, other cheaper during night, and I just alternate between
them.

> would cost if you need to renumber your complete site.

Hmm.. maybe this could be my retirement job. Can I be the
"registrar"?. It might be nice cash flow for very little work.

> Still no reason for keeping SL's...

Still, can keep them in spec as is.

- nobody forces you to use SL's on your site, if you don't want. It's
  just an option for those who think they can take advantage of it.

- applications do not need to care about them. They just SL's as any
  other address.

- IPv6 stacks have already been impelmented based on scope
  addressing. There is the source address selection rules, also
  implemented. It hurts noone to keep the current spec AS IS.

---

From: [email-masked]
Date: Thu, 03 Apr 2003 00:25:05 +1000

> lowering *transit* traffic.

	They still have to be caught and machines have to return
	NXDOMAIN.  These machines are NOT being paid for by the
	people who are leaking the traffic.
 
> to another site or the internet.

	Well if they are not connected at all there is no costs to
	be bourn by eveyone else.

---

From: Mike Saywell <[email-masked]>
Date: Wed, 2 Apr 2003 15:27:05 +0100

> would cost if you need to renumber your complete site.

Think beyond corporate networks.

SL does not lead to NAT but choosing random addresses *WILL*, consider:

I setup an ad-hoc network using my laptop, wireless is 1 network and
wired is a second, my laptop routes between them.  There is no external
connectivity and site-locals are deprecated so I pick a random prefix.

Now somebody with a link to the wider world joins my network, since there
is no guarantee that the prefix used on the ad-hoc network is not used
on the internet you either have to nat outgoing traffic or re-number
the network.  You have repeatedly slated re-numbering, and it seems
un-feasible in an ad-hoc network anyway so the only choice left is NAT.

If the network was numbered using site-locals all you don't need to
re-number, just advertise an additional prefix.

Yes, applications would need to be made to use the global prefix, we
need a way of enforcing this - a simple method could be that the O/S
simply deprecates the site-local prefix.

If you only consider that Site-locals will ever be deployed in a "normal"
network then the deprecation question is easy (yes deprecate them),
however I thought that one of the advantages of v6 was that it gives
better support for the a-typical network.

I dont think some organisation allocating private prefixes is viable
either, ad-hoc means exactly that, I don't want to be manually entering
my unique private prefix.

How about using fec0:<MAC address>::/64?  That gives a (probably) private
network per interface, the only issue is that you wouldn't be able to
aggregate them in a sizeable network - however I agree that site-locals
shouldn't be used in such a scenario. :)

Mike

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 2 Apr 2003 16:43:29 +0200

> during day, other cheaper during night, and I just alternate between

Great example for a use of multihoming. Also who says your
prefix becomes 'instable' when you swap it from the night to the day
ISP?
Also if you swap your ISP without multihoming it will break
connections to the rest of the internet, read: rest of -> non site
local.
I don't see the need for site-local here either. I do see
the need for PI/multihoming though.
Maybe you are mixing 'global' a /48 (site-global :) with site-locals?

> "registrar"?. It might be nice cash flow for very little work.

It could be indeed, go set it up.
Why do you think that the domainname business is so good?
Virtual money for virtual bits! Thats why there has been
so much contraversy. But some entity needs to regulate it.
Also you 'rent' the domainnames/space, you do not own it.

>   just an option for those who think they can take advantage of it.

True, bad it is also a bad option that will cause many problems.
You might see the problems ahead but $manager won't. And that's
why there needs to be a replacement for this.
 
> - applications do not need to care about them. They just SL's as any

That would be a good thing. But how are you solving the:
AL talks to BL and B passes A's address to CG case?
Or are you talking about completely disconnected sites again?

>   implemented. It hurts noone to keep the current spec AS IS.

See the case above and the numberous of other problems presented
througout the thread and in the presentations.

Greets,
 Jeroen

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 2 Apr 2003 16:59:06 +0200

> > would cost if you need to renumber your complete site.

You accidentally cut out the following lines from the reply
above this one which does make a big difference in the rest

> > not everybody starts harvesting them.

<snipback>

> wired is a second, my laptop routes between them.  There is 
> no external connectivity and site-locals are deprecated so I pick
> a random prefix.

This looks like a typical house style network... just like mine
except that I got a machine which gates these two nets to the internet
just like you explain in:

> Now somebody with a link to the wider world joins my network, 
> since there is no guarantee that the prefix used on the ad-hoc
> network is not used on the internet you either have to nat
> outgoing traffic or re-number the network.
> You have repeatedly slated re-numbering, and it seems

Announce the new prefix, deprecate the old prefix done.
Small networks don't really care about having to edit a couple
of places where hosts<->ip are registered which should quite
probably only be DNS and a single firewalling place.
That's the joy of small non-corporate networks.
For SOHO usage this will boil down to a click-and-pray interface.

> re-number, just advertise an additional prefix.

And why can't you just advertise an additional prefix when having
some space that is globally unique and private as that's where it
is registered for (see the text above that was cut away :) ?

> simply deprecates the site-local prefix.

What I stated above.

> If you only consider that Site-locals will ever be deployed 
> in a "normal" network then the deprecation question is easy
> (yes deprecate them), however I thought that one of the
> advantages of v6 was that it gives better support for the a-typical
network.

Name these a-typical networks. Otherwise there can be no cases for them.
I do still like the boat case :)

> my unique private prefix.

You have to enter a site local prefix too.
Whats the difference in entering a unique prefix or typing
in 10.0.0.0/8 again?

Most people will want to connect to the internet. So especially
for SOHO cases they will be connected to the internet. Their ISP
will provide them with a /48 either through router advertisements
or using the old fashion paper way. SOHO routers will simply
ask "please enter the prefix as stated on the paper" and done.
We are fortunatly taling SOHO here and 

> aggregate them in a sizeable network - however I agree that 
> site-locals shouldn't be used in such a scenario. :)

Hmmm that does sounds like a good idea for an alternative.
It does indeed overcome the 'registry' problem and the fact
that it should be globally unique. Except that one would rather
use EUI-64 instead of the MAC address. But that's ofcourse debatable.
I would rather see use of the fec0::/10 in a way like this than
with every sole person using fec0::80 for their home webserver...

Greets,
 Jeroen

---

From: Steven Blake <[email-masked]>
Date: 02 Apr 2003 10:33:31 -0500

> in the current address architecture, i.e. FEC0::/10.

Do you mean the e-mail where you said the following?

--> I prefer to think about this the other way round: kill the ambiguous
--> space, which we have learnt the hard way is a mistake, and then
--> design the alternative, which may well be unrouteable GUPI (and for
--> all I care, starts with FEC::/10).

> what else we could be referring to.

Well, I'm still confused.

---

From: "Jeff W. Boote" <[email-masked]>
Date: Wed, 02 Apr 2003 08:35:32 -0700

>         "YES -- Deprecate site-local unicast addressing".

Ambiguous addresses are a nightmare...

---

From: Mike Saywell <[email-masked]>
Date: Wed, 2 Apr 2003 17:06:08 +0100

> just like you explain in:

No I meant it's an ad-hoc network where devices want to communicate ones
*before* there is a global prefix.

> Announce the new prefix, deprecate the old prefix done.

Not that simple really...  The first prefix was advertised by my laptop,
the true global one is advertised by e.g. a mobile phone.  What if the
phone then leaves?  Renumber again?

Deprecating isn't good enough either you need to totally remove the
prefix otherwise the hosts will still consider the prefix on-link.

> probably only be DNS and a single firewalling place.

If it's a home user they might mind (or not know how!)...

> You have to enter a site local prefix too.

Not if the ad-hoc routing protocol assigns/negotiates one...

Mike

---

From: stanislav shalunov <[email-masked]>
Date: 02 Apr 2003 11:14:26 -0500

YES -- Deprecate site-local unicast addressing.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Most people can do nothing at all well.              -- G. H. Hardy

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 2 Apr 2003 08:15:24 -0800

Brian E Carpenter wrote:
> I think we should clear the desktop first, by getting rid of 
> ambiguous site-local address space, and then discuss possible 
> new solutions.
> 

And many feel that deprecating without a solution in hand is the wrong
order. A solution in hand has considerably more value than a promise
from a group that refuses to acknowledge that some of the goals of
network managers are valid.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 2 Apr 2003 08:21:41 -0800

Jeroen Massar wrote:
> ...
> If someone doesn't want/like this they can pick a random 
> number and use that, they still have to renumber when they 
> interconnect to another site or the internet.

Renumbering in an IPv6 context means adding a prefix. Unlike IPv4 it
does not mean removing the existing one. There is no reason for a site
that connects to have to renumber nodes that are not going to use the
external connection. Get out of the IPv4 mindset.

Tony

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 2 Apr 2003 18:41:48 +0200

> external connection. Get out of the IPv4 mindset.

If you use 'site-local' as a local prefix then you will have to
renumber those boxes to be able to get global connectivity.
Even if the 'site-local' prefix stays onlink you will need
to do renumber in DNS and other configuration items to get
global connectivity working on the incoming part.

And if your fec0::/10 matches the other parties fec0::/10 also
have fun renumbering or are you going for the NAT again?
Otherwise have fun setting up the routing and other stuff.

Also I wonder why you call it IPv4 mindset; as for as long
as I have known there have been alias devices, heck even
on NT, one can set multiple IP's/subnets per interface.
By hand, not per DHCP but even then.

Btw does DHCPv6 allow for multiple multiple prefixes?
Eg when there are multiple DHCP servers?
I didn't check the spec as RA's work just fine, except
for the fact that there is no dns server in there (yet).

Greets,
 Jeroen

---

From: Andrew White <[email-masked]>
Date: Thu, 03 Apr 2003 02:35:20 +1000

> shouldn't be used in such a scenario. :)

There are currently two drafts that describe how to implement this.  There
are surface differences, but the basic idea is the same.

  * draft-hinden-ipv6-global-site-local-00.txt
  * draft-white-auto-subnet-00.txt

-----

As for site locals, there seem to be three issues: scope, ambiguity,
renumbering.

On scope:

If you only ever have on address per machine (strictly no multihoming) then
scope isn't an issue.  However, renumbering becomes awkward.

If you allow multihoming, then either you must ban filtering or all
applications need to be able to compensate for situations where some
source-destination address pairs work and some don't.  Architectural scoping
doesn't make the problem worse, and may make it better by providing hints to
applications if they choose to pay attention.

On ambiguity:

In most sensible SL deployment scenarios, ambiguity is not an issue. 
Disconnected networks don't matter, while any other SL network is not
supposed to talk outside the site, and so things will happily fail.  And if
someone else's DNS returns an SL?  Well, the packet gets dropped at the
filter on your site border router.  This is slightly better than any other
bad DNS result where the packet is dropped somewhere in the global internet.

On renumbering:

Most of the ambiguity questions are really renumbering questions.  For
'large' sites, you can go provider-based (renumbering is potential issue),
or site-local (and be unrouteable), or NAT (yuck!), or PI (doesn't currently
exist).  Multi-homing at least helps things, in that you can switch in your
new addresses before you switch out your old.

If you wish to run an internal non-routeable address space, there are
several proposals to allow site-local address realms to be set-up such that
they are probably (or guaranteed) globally unique (without requiring
registration), which solves the local merge problem.

On the other end of the spectrum are zeroconf networks that may or may not
be connected to a global provider.  SL and multihoming is perfect for these
networks, since they can zeroconf in the SL space and then overlay a global
address space if convenient.

And zeroconf networks don't have nearly the same renumbering problems as
large configured networks, because they are designed to rebuild all that
configuration information without human agents.

Finally, there is advantage to using SL in private, disconnected networks,
and that is that those networks may eventually join the global internet.  If
you have used SL, you know that you can continue to use that space locally
without masking global connectivity, and overlay a global address.  If you
picked an arbitrary address, then you may have ambiguity that matters,
rather than ambiguity that doesn't.

I'm all in favour of an 'SL considered harmful'.  However, there are several
situations were SL is exactly what is appropriate, and it seems an odd
philosophy to deprecate power-saws because they shouldn't be used in place
of drills.

-- 
Andrew White                [email-masked]

---

From: Mika Liljeberg <[email-masked]>
Date: 02 Apr 2003 20:16:36 +0300

- Site-locals should be retained for disconnected sites.
- Site-locals should be retained for intermittently connected sites.
- Site-locals should be retained for their access control benefits.
- Site-locals should be retained as a means for internal connections to survive global prefix renumbering.

- Other: site-locals should be retained as an easily recognizeable
alternative to non-globally reachable global addresses.

	MikaL

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 2 Apr 2003 20:37:16 +0200

>   * draft-white-auto-subnet-00.txt

I personally can see use in these two drafts.
But not in the current setup for SL.
These at least take the problem away that a
site is unique which saves on the renumbering problem
when 'unconnected' sites connect.

> If you only ever have on address per machine (strictly no 
> multihoming) then scope isn't an issue.  However, renumbering becomes
awkward.
> source-destination address pairs work and some don't.  
> Architectural scoping doesn't make the problem worse, and may make
> it better by providing hints to applications if they choose to pay
attention.

Having multiple prefixes will most of the time imply
that the layers above know a bit about the network. Though
ignorance is bliss in this case as the current source-address-
selections protocols will select the correct prefix in most
cases based on longest prefix matching algorithms.

> supposed to talk outside the site, and so things will happily 
> fail.  And if someone else's DNS returns an SL?  Well, the packet gets

> dropped at the filter on your site border router.  This is slightly
better 
> than any other bad DNS result where the packet is dropped somewhere in
the 
> global internet.

There does start a problem where the deployment is not sensible.
AS112 is the proof of this. Explicetly having a certain prefix
filtered on SOHO devices could be an option, but this also implies
that IPv6 will be going that dreaded NAT way if the upstream
doesn't provide enough address space.

Talking about that, maybe a clause in some document should hint
ISP's to start billing based on traffic consumption and not on IP
usage. "IP usage" is a unmeasurable thing when the endsite gets
a /48 unless the ISP is going to sniff all the packets and account
them that way instead of based on the circuit counters.
This would at least hint them that endsites should really get
a /48 and not just a single /128. Personally I would shoot ISP's
who did not follow that convention. Then again one can always
ask them why the peep they requested a TLA in the first place
if they are not going to give their endsites /48's.

<SNIP>

> I'm all in favour of an 'SL considered harmful'.  However, 
> there are several situations were SL is exactly what is
> appropriate, and it seems an odd philosophy to deprecate
> power-saws because they shouldn't be used in place of drills.

With the above 2 drafts in mind we only will be deprecating
the current version of SL. One, or a merger, of the above
two drafts will make the power saws into a workable saw
which doesn't smash up the wood (ambiguity) nor doesn't
need any power (registration).

Greets,
 Jeroen

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 2 Apr 2003 11:34:34 -0800

Jeroen Massar wrote:
> ...
> Talking about that, maybe a clause in some document should 
> hint ISP's to start billing based on traffic consumption and 
> not on IP usage. "IP usage" is a unmeasurable thing when the 
> endsite gets a /48 unless the ISP is going to sniff all the 
> packets and account them that way instead of based on the 
> circuit counters. This would at least hint them that endsites 
> should really get a /48 and not just a single /128. 
> Personally I would shoot ISP's who did not follow that 
> convention. Then again one can always ask them why the peep 
> they requested a TLA in the first place if they are not going 
> to give their endsites /48's.

Demand RFC 3041 support for your devices.

> need any power (registration).

Wrong, because they are not defining /48's.

Tony

---

From: Hans Kruse <[email-masked]>
Date: Wed, 02 Apr 2003 14:27:33 -0500

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax
--------------------------------------------------------------------
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: Antonio Querubin <[email-masked]>
Date: Wed, 2 Apr 2003 17:20:21 -1000 (HST)

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 3 Apr 2003 13:33:20 +1000

... until such time as we have a proposed provider-independent,
administration-free allocation method for 'disconnected'
networks, perhaps GUPIs or similar.

... at which time we can do a consensus call of: "Should we
deprecate SLAs as per RFC X in favour of XXXA's as per draft XXX.

I feel that SLAs provide:
	
	1. A useful address space for non-routable backend
	networks, eg: SANs.  Because of their 'site local' 
	status, a site-edge machine can easily tell if an
	address is 'in' or 'out' at the Application Layer.

	2. A useful, large, free, experimental space. 

-----N
-- 
Nick 'Sharkey' Moore			<[email-masked]>
Research Fellow, CTIE			Tel: +61 3 9905 3707
Monash University,  Australia		Fax: +61 3 9905 5358
--------------------------------------------------------------------
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: "Jim Fleming" <[email-masked]>
Date: Wed, 2 Apr 2003 21:47:13 -0600

From: "Nick 'Sharkey' Moore" <[email-masked]>
> address is 'in' or 'out' at the Application Layer.
====

The a PeaceKeeper (PK) by definition has a connection to both the IPv8 transport and the IPv16 transport.
Applications know why they are using either transport, and can of course use both or start with one and fall
back to the other, etc. The users are behind the GK (NAT) appliances and of course have no access to the
IPv16 transport, unless it is via a PK.

Jim Fleming
http://www.IPv8.info

---

From: Atsushi Onoe <[email-masked]>
Date: Thu, 3 Apr 2003 12:59:58 +0900 (JST)

Atsushi Onoe

---

From: Andrew White <[email-masked]>
Date: Thu, 03 Apr 2003 14:10:08 +1000

While not primarily an access control mechanism, site-local addresses can be
part of an access control solution - any machines that have only site local
addresses will not have global accessibility (assuming correct filters).

In a network with filters and multi-homing, site local addresses seem to
impose no additional complexity on applications (see list message from
Sun/Mon), and may provide hints if the application wishes to pay attention.

I am in general agreement with the "Moderate" model documented by Bob Hinden
after the last IETF (the one presented in the slides at the recent IETF
seems to differ in some small but significant ways) and in agreement with
Tony Hain's recent draft.

Finally, I've seen several decent enhancements for some perceived SL
issues.  I haven't seen satisfactory alternatives for the key SL deployment
scenarios.

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 03 Apr 2003 15:43:19 +0900

Daniel

-----Original Message-----
Sent: Wednesday, April 02, 2003 4:38 AM

Hi All,

The question is:

Valid responses are:

---

From: Christian Schild <[email-masked]>
Date: Thu, 3 Apr 2003 10:44:54 +0200

Am Dienstag, 1. April 2003 21:37 schrieb Margaret Wasserman:

- Without SLs it is no longer possible to connect two local links to 
  each other. This is the basic feature of a site-local address, to
  connect two links without a global prefix. Any additional (global)
  feature for SLs is dangerous. Maybe just rename "site-local prefix" 
  to "private prefix".

Christian

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 03 Apr 2003 11:02:18 +0200

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

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

---

From: Fredrik Thulin <[email-masked]>
Date: Thu, 3 Apr 2003 11:58:25 +0200

/Fredrik

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Apr 2003 07:51:45 -0500

Hi Jinmei,

At 02:36 PM 4/2/2003 +0900, JINMEI Tatuya / 
>followed the very recent discussion in the ML, but I cannot be sure

We did not reach a specific consensus on this point.  The WG was
attempting to choose an overall direction, after which we acknowledged
that there would be further work to do in either case.

If we choose to deprecate site-locals, we will need to settle on
alternative methods to deal with local addressing, access control, etc.

>essential advantage over the existing fec0::/10 (with eliminating the

I agree.  I think that it would be much better to get registries to
allocate unique prefixes for use on local networks.  People who are
ISP connected might also have the option of using part of their
ISP-provided /48, if they are not motivated by ISP-independence.

But, even randomly chosen values (the worst possible alternatives in
many ways) are better than site-locals, IMO.

>important -from my personal perspective- issues.

Yes!  This is the big motivation for deprecating site-locals.  It
will allow us to _finish_ IPv6 and move on.  Someone may want to
work elsewhere in the IETF/IRTF on the issue of scoped unicast
addressing, and I would support their work.  But, this idea isn't
baked enough to include in a protocol that is becoming widely
deployed as we speak.

Removing half-baked ideas (even promising ones) from the architecture
is a normal process as specification mature.

Right now, the unresolved issues with site-locals are blocking
progress on the scoped addressing architecture, which is vitally
needed to complete the IPv6 specifications.

>So, even if the

While it would certainly be better to have a means to allocate
globally unique private addresses, the operators present at the IPv6
WG meeting in SF were adamant that even using randomly chosen
prefixes for local networks would be superior to site-local
addresses, given the complexity and issues associated with site-locals.

Besides, we will need another method for private addressing, anyway,
as you cannot nest sites, and many people do nest access control
boundaries.

Margaret

---

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

If you use this method to generate unique local addresses (which
may be one viable alternative), you still won't want the semantics
of current site-local addressing...

The current site-local architecture does not allow sites to overlap
or be nested.  Sites also need to be "convex" which requires that
their boundaries be at routing area or AS boundaries.  Current
site-local addresses are ambiguous, so they need to be treated
specially in address selection rules, at UIs, etc.

If you come up with any method to generate unique local addresses
(mac-address-based, registry-based, etc.), then most of the
restrictions in the current site-local architecture are unnecessary.
Unique local addresses don't need to be treated as "scoped" addresses
(in the sense this term is used in the scoped addressing architecture).
They can be treated just like any other global addresses, and
just filtered at the borders of the local space.

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Apr 2003 16:00:36 +0200

> --> all I care, starts with FEC::/10).

yes

> Well, I'm still confused.

what do you think we are possibly deprecating, if it isn't the
current definition?

   Brian

---

From: Steven Blake <[email-masked]>
Date: 03 Apr 2003 10:49:22 -0500

> what do you think we are possibly deprecating, if it isn't the

There have been several proposals to turn addresses in fec0::/10 into
GUPIs or PUPIs (Probabilistically Unique PIs), similar to your note
above).  Since I wasn't in SF, I wanted to make sure that we weren't
being asked to preclude those as well.

For whatever it is worth, I think that ambiguous addresses are a
disaster, but nothing is going to prevent those that want RFC 1918-style
addresses from inventing them.  It is better to have a well-defined
prefix for this, rather than risk the chaos of people creating them out
of the global space.

I would be happy to see fec0::/11 set aside for private/experimental
(including PUPIs), and fee0::/11 set aside for GUPIs.  Any notion of
site ID should be ripped out of all the specs.

Regards,

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 04 Apr 2003 03:16:57 +0900

>>>>> On Wed, 02 Apr 2003 14:36:19 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> followed the very recent discussion in the ML, but I cannot be sure

Thanks, everyone.  Since my goal was to clarify a background of this
vote (for myself), I won't make a response to each follow-up.  I
believe I now understand the background.  A rough summary is:

  If we say "YES -- Deprecate site-local unicast addressing", this
  means we agree on removing site-local assuming something fantastic
  that can solve issues when we really remove it.

Hmm..., then it is natural that the group of 'YES' will be in a
majority.  And, in fact, the "something" seems to vary among people.
It even contains, if I understand the discussion correctly,
"nearly-unique site-local" that consists of fec0 + some_random_bits.

I agree even "nearly-unique SL" is better than the current fec0::/10,
and, in that sense, I can vote for YES (Note: I don't stick to this
one.  I'm picking it up as an example).  However, can we really agree
on using this particular solution?  Some people is against SL due to
its "false sense of security", which also applies to the
"nearly-unique" one.  So they will also be against this.

So..., I'm afraid we'll just end up having a discussion loop again or
even re-inventing yet another site-local addresses (which will then
cause another loop), due to the very large notion of 'YES'.  For this
reason, I cannot agree on just "clearing the desktop first".  I cannot
believe this approach stops the circle.

As I have repeatedly said, I'm not a site-local lover, so I'd rather
vote for 'YES'.  But, in this current form, I cannot do that.

At this moment, I don't have a good idea to overcome this dilemma.
I'll try to think more about it (of course, I'll be very happy if
someone can enlighten me on this, without repeating points already
stated in this thread).

Thanks,

					JINMEI, Tatuya

---

From: Wataru Kawakami - One user of current IPv6 <[email-masked]>
Date: Fri, 04 Apr 2003 07:05:29 +0900

- Before deprecating site-locals for disconnected sites, well defined 
    alternative address block should be RFC'ed, not to rewind the history.

--
Site-Local address seems to be the nearest candidate to be used 
as ``local'' (locally used without interconnection to the Internet) 
address. (In IPv4, so called ``private address'')

``Local'' address is quite useful tool for operators of enterprise's 
network to provide good security for the users within the enterprise's 
network.

In old days, I've heard that IPv4 global address was used as ``local'' 
address, undergroundly, before RFC-1918 was made.

Deprecate of Site-Local Address without defining alternative for 
``private'' address, in previous, may cause the history to rewind 
again.

May turn to ``Yes'', if any *private* address block is defined 
as RFC *before* deprecate of Site-Local Address, and the *block* 
could be used freely, as RFC-1918 in IPv4 world.

Just my comments follows;
--
It is quite *hopeless* that ISPes will deliver ``private address''
for users, without fee.
At IPv4 world, to my poor understanding, ordinary ISP may not assign
me any global address, if I'm not the customer of the ISP.
--
Wataru Kawakami, Japan.
--------------------------------------------------------------------
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: Tim Chown <[email-masked]>
Date: Fri, 4 Apr 2003 01:34:40 +0100

> Not if the ad-hoc routing protocol assigns/negotiates one...

Note also in Mike's scenario he needs /48's to networks attached to
the community mesh, so the /10 property of a site-local is required,
and solutions which may allocate "random", non-aggregating /48's or
even /64's are not so desirable.   Also, some nodes on the network have
access to uplinks, some do not, yet all should be able to communicate
internally.

Enquiries to get a global prefix under the current schemes have not
been successful; the community network would need to find the $$$ for
LIR fees.  A site local /10 is free.

Tim

---

From: Alex Zinin <[email-masked]>
Date: Thu, 3 Apr 2003 22:24:37 -0800

reasons += adds complexity to routing, forwarding, and network operations;

--
Alex Zinin

P.S. Though I was in the room in the beginning of the WG meeting,
     I left it before this discussion started...

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 04 Apr 2003 11:57:19 +0200

I was in San Francisco, but not in the room.

Note: By "Deprecate Site-Local", I mean "Do not require any application, 
host, router, protocol or IETF practice to have to make special 
consideration for the idea that an IPv6 unicast address outside of the 
link-local range can refer to two different hosts".

In particular, that the drawings in draft-ietf-ipngwg-scoping-arch-04.txt 
showing zone indices need never have more than 2 levels (interface-local 
and link-local), that all 70 references to "site" in this document can be 
removed, and that section 12 of that draft (textual representation of 
zone-ids) can be removed, or reworded to deal with debugging tools for 
link-local only.

By "Deprecate", I do not mean "Allocate the FEC0::/10 prefix to the RIRs 
for normal allocations". That would be stupid.

                  Harald

---

From: Bill Manning <[email-masked]>
Date: Fri, 4 Apr 2003 02:49:00 -0800 (PST)

% "YES -- Deprecate site-local unicast addressing".
% 
% reasons += adds complexity to routing, forwarding, and network operations;
% 
% --
% Alex Zinin

	waxing nostalgic...  IPv6 was supposed to be an enabler of a whole
	raft of interesting new capabilities.  based on your concerns, listed
	above, IPv6 is going to be nothing more than IPv4 with larger address 
	space.  if that is what we end up with, then IPv6 development might
	be considered a waste of time.  we could support the premise of IPv6
	(10x16th nodes...?) using Paul Francis's  nifty idea of a box that will
	do address translation and never need to move away from a 32bit address
	space.

	IPv6 had (and perhaps still has) the ability to allow us to develop
	alternative routing techniques, where aggregation is not the only 
	abstraction that is viable. 

	For me the vote (and it is a vote...) seems to break down along these
	lines:

Yes - those who wish to maintain the status quo or have vested commercial
	interests in shipping IPv6 product.
No  - those who wish to explore the latent capabilities of IPv6.

	as usual, YMMV and my understanding is likely flawed.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
--------------------------------------------------------------------
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: Patrik Fältström <[email-masked]>
Date: Fri, 4 Apr 2003 13:11:15 +0200

On fredag, apr 4, 2003, at 12:49 Europe/Stockholm, Bill Manning wrote:

>    based on your concerns, listed
> 	be considered a waste of time.

I don't think IPv6 will be (much) more than IPv4 with larger address 
space, BUT, that is not a small thing. It is something that would be 
really really nice to have. I am tired on writing ton of paper to my 
local ISP, which add tons of paper and send to their upstream provider 
which send something to RIPE NCC, which respond, and then 15 roundtrips 
later and two renumberings of the local network I might expand my /28 
to a /27.

I am tired of this! I am tired on not being able to give real IP 
addresses to guests which visit me. I am tired on not being able to 
give real IP addresses to my IP phone. I am just so incredible tired.

So I want IPv6, even if it is *just* IPv4 with larger address space.

For really different Internet, I think we need something like:

  - Real differentiation between routing identifier and globally unique
    addressing identifier for a node (and not use one IP address for 
both)
  - The ability to change the routing identifier during flight
  - Routing protocol(s) which really is tuned to the fact that the
    Internet is a mesh and not a hierarchy anymore
  - ...and many more things...

As Harald wrote:

> Note: By "Deprecate Site-Local", I mean "Do not require any 
> application, host, router, protocol or IETF practice to have to make 
> special consideration for the idea that an IPv6 unicast address 
> outside of the link-local range can refer to two different hosts".

We need to, until we have better mechanisms overall, make sure we keep 
applications so they can deal with addressing, while the network take 
care of the routing.

Mixing will not work. Especially as we don't have real solutions to the 
real problems.

So, when I say I want Site Local deprecated I mean I want routing and 
addressing separated, and given that separation, we have to work on 
solving the real problems we have with Internet today.

    paf

---

From: [email-masked]
Date: Fri, 04 Apr 2003 09:52:52 -0800 (PST)

Ned

P.S. I was unable to attend the ipv6 meeting due to the conflicting
     ASRG meeting.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 04 Apr 2003 13:56:25 -0800

Bill, I think what your missing is that to many of us, IPv6's selling 
points sum up to the following two things (the others pale):

1.  Large address space
2.  Mobility

(1) is not necessary with site-locals.  Since we have established that
site-locals will encourage the use of NATs ('cause that's how it's done 
today) we might as well stick with the existing NAT'd infrastructure.
If people vote "No", the benefits of a NAT-free world having evaporated, 
I see no reason for anyone outside of the mobile folks to move forward 
with IPv6, since what we have works comparably well with IPv6.

And another thing- Tony keeps talking about acting irresponsibly by 
taking away a mechanism for which we otherwise have no solution.  Of 
course we have a solution- IPv4 with NATs.  This gives us some time to 
come up with something better for v6.

Eliot

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 04 Apr 2003 17:22:56 -0500

DO NOT DISCUSS THINGS IN THIS THREAD!  (<-- yelling :-)).

Please change the subject.

Thanks,
Margaret

At 01:56 PM 4/4/2003 -0800, Eliot Lear wrote:
>If people vote "No", the benefits of a NAT-free world having evaporated, I 
>see no reason for anyone outside of the mobile folks to move forward with 
>IPv6, since what we have works comparably well with IPv6.
>
>And another thing- Tony keeps talking about acting irresponsibly by taking 
>away a mechanism for which we otherwise have no solution.  Of course we 
>have a solution- IPv4 with NATs.  This gives us some time to come up with 
>something better for v6.
>
>Eliot
>
>Bill Manning wrote:
>
>>% % reasons += adds complexity to routing, forwarding, and network 
>>operations;
>>% % --
>>% Alex Zinin
>>         above, IPv6 is going to be nothing more than IPv4 with larger 
>> address   space.  if that is what we end up with, then IPv6 development might
>>         alternative routing techniques, where aggregation is not the 
>> only       abstraction that is viable.

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 4 Apr 2003 14:57:51 -0800

YES, I'm in favor of deprecating the IPv6 site-local scope prefix fec0::.

This, in spite of the fact that we have an existing IPv6 product for
embedded systems that includes support for the site-local scope prefix, plus
places in our source code and user documentation where site-local scope is
referenced, etc.

It is important to simplify IPv6 DNS, routers and source address selection.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com
P.S. - I just wanted to make sure this appears in the correct thread, that's
why I resent it.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 4 Apr 2003 21:17:38 -0800

Bill,

>         above, IPv6 is going to be nothing more than IPv4 with larger address 

I don't believe we should do something just because we can. Added
complexity needs justification in the form of clear benefits. Extra
operational complexity needs even more justification.

From what I've seen so far, benefits of SLs are questionable, while
complications are introduced throughout the protocol stack.

> if that is what we end up with, then IPv6 development might

Interesting... Lack of SL support in many router implementations
does not make people less interested in IPv6...

>         abstraction that is viable. 

If those appear just because we can do so, I'd be skeptical. If
because they solve a real problem and added complexity is not
frightening--sure.

Alex

---

From: Sebastien Roy <[email-masked]>
Date: Sat, 05 Apr 2003 18:49:47 -0500

-Seb

---

From: Masahiro =Rhythm Drive= Ishiyama <[email-masked]>
Date: Mon, 07 Apr 2003 20:48:27 +0900

Note: If we have a good solution for disconnected sites, I'll
	vote for YES. I saw several ideas on this list, but I'm not
	convinced yet. So I'd like to say NO at this time.  

  ---------------------------------------
    Masahiro ISHIYAMA                  
    Communication Platform Laboratory, 
    R&D Center, TOSHIBA CORPORATION
  ---------------------------------------
--------------------------------------------------------------------
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: Tue, 08 Apr 2003 02:47:16 +0900

>>>>> On Tue, 01 Apr 2003 14:37:56 -0500, 
>>>>> Margaret Wasserman <[email-masked]> said:

- because I'm not convinced that there is a clear consensus on an
  alternative to site-local or that we do not need such a consensus.

I'm sad I must vote for NO...I've tried to convince myself by
the meeting minutes, presentation slides, discussion in this list, and
some private discussion, but I failed.

I've seen many candidate alternatives that at least include:
  - arbitrary (random) global prefix
  - fec0:: + random bits
  - free prefix allocation service

I've even seen a wording nit like:
  - leave site-local in the spec, but make a recommendation to avoid
    using it.
  (but can't this also be interpreted as a sort of 'not deprecate
  site-local'?)

I could not be sure if we'll be able to make a consensus on any of
them (or others) quickly, if we choose "deprecating" site-local.  If
not, the result will just be a confusion.  If we can, then I don't see
why we cannot first make a consensus quickly and then deprecate
site-local.

I (of course) don't know the final result of this vote at this
moment.  But regardless of the result, I'm willing to follow it
without making a further objection, and will try to make a productive
contribution based on the result.

					JINMEI, Tatuya

---

From: Vladislav Yasevich <[email-masked]>
Date: Mon, 07 Apr 2003 15:52:00 -0400

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

---

From: Havard Eidnes <[email-masked]>
Date: Mon, 07 Apr 2003 23:19:32 +0200 (CEST)

- Håvard

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 8 Apr 2003 08:57:27 +1000

On Fri, Apr 04, 2003 at 01:34:40AM +0100, Tim Chown wrote:
> even /64's are not so desirable.

Mike's working on Globally-Routable Provider Independent Addresses,
I think ... which, if they can be made aggregatable, arguably deserve
their own X::/3.

-----N

---

From: Mitsuru KANDA / 神田 充 <[email-masked]>
Date: Tue, 08 Apr 2003 13:26:37 +0900

NO -- Do NOT deprecate site-local unicast addressing.

It's need for disconnected sites

----------------------------------------
Mitsuru KANDA ([email-masked])
 Toshiba Reseach & Development Center
       Communication Platform Laboratory ([email-masked])
 USAGI Project ([email-masked])

.

---

From: Johan Nicklasson <[email-masked]>
Date: 08 Apr 2003 13:30:19 +0200

//Johan
-- 
Johan Nicklasson <[email-masked]>

---

From: Hans Kruse <[email-masked]>
Date: Mon, 07 Apr 2003 17:43:59 -0400

Thank you!  I have been trying for the past few days to explain how/why I 
came down on this side of the "vote", but you did a much better job than 
anything I had tried so far.

Some comments inline with the edited message:

--On Tuesday, April 08, 2003 02:47 +0900 "JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" <[email-masked]> 

> some private discussion, but I failed.

I agree.

> why we cannot first make a consensus quickly and then deprecate

This is what I was trying to express, too.  Maybe my "No" was more a 
statement on the (perceived) process.

I mainly create, design, manage, and use research networks; many ad-hoc and 
transient, many for teaching purposes. Therefore:

I DO NOT want anyone (least of all my students or new net admins) picking 
random prefixes for disconnected networks.

I DO need readily available (non-routable) prefixes for disconnected and 
intermittently connected networks.  While I can live with ambiguous ones 
for my stuff, I realize that they cause problems, and I will gladly go 
through a reasonable registration process to get unique ones (or create 
them with an autoconfig process); but these prefixes MUST BE recognizable 
(so they can be easily and readily filtered not just by me but by anyone 
without them knowing the prefixes I am currently using), and they cannot 
depend on a contractual relationship with an ISP or registry.

I hope the outcome of this exercise can be a document that simultaneously
- creates a "site local lite" concept that deals with a reasonable subset 
of the issues brought out over the past week,
- lays out the roadmap for what still needs to be solved,
- pulls the original site-locals out of future address architecture docs.

Possible?