Subject: Re: Draft IPv6 Minutes from Atlanta IETF

From: Bob Hinden <[email-masked]>
Date: Fri, 28 Mar 2003 13:07:27 -0800

Sorry, the subject should have been "Draft IPv6 Minutes from the San 
Francisco IETF".  The minutes are OK.

Bob

At 01:05 PM 3/28/2003, Bob Hinden wrote:
>Draft IPv6 working group minutes from the San Francisco IETF are attached.
>
>Please review and send comments.
>
>Thanks,
>Bob
>

--------------------------------------------------------------------
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: Bob Hinden <[email-masked]>
Date: Fri, 28 Mar 2003 13:05:19 -0800

Thanks,
Bob

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 28 Mar 2003 16:43:23 -0800

It is interesting that Erik pointed out there was not enough information
to make a decision due to lack of agreement about the requirements, yet
that was ignored and the decision was made to press on and call a
question that was not even on the agenda ...

From the minutes, the characterizations I heard that the decision was
based on fear of NAT appears to be correct as comments about it are
liberally spread through the discussion. In particular they appear in
the summary discussion right before the question. This subterfuge only
furthers the lack of understanding about what site-local is. Local
address space is a filtering function, and exists with or without header
mangling. Filtering will exist in real network deployments, so having a
space set aside for that purpose does not change the architectural
reality. 

I agree that much of the group doesn't understand the requirements of
the network managers, so I have started a draft on that subject. Granted
this is an early pass, with content based primarily on previous email,
but it does provide a basis for discussion. Comments requested:
http://www.tndh.net/~tony/ietf/site-local.txt

Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Friday, March 28, 2003 1:05 PM
> To: [email-masked]
> Subject: Draft IPv6 Minutes from Atlanta IETF
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 Mar 2003 17:10:42 -0800

Actually the filtering you mention in the draft set was thought of at 
the time of RFC 1597.  The result was that it set back ISP security 
years if not decades.  ISPs needed a default deny with explicit permit 
model whereas site-locals and their predecessors allow for a lazy 
default permit policy.  While RPF is useful and good, better is a 
default-deny model.

Eliot

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 28 Mar 2003 17:17:56 -0800

Eliot Lear wrote:
> While RPF is useful and good, better is a 
> default-deny model.

Those are orthogonal concepts. Route filtering is about limiting the
ability to return traffic to a site, while RPF is about enforcing that a
site is sourcing traffic from a valid prefix. Both are required.

Tony

---

From: Tim Chown <[email-masked]>
Date: Sat, 29 Mar 2003 22:18:09 +0000

> http://www.tndh.net/~tony/ietf/site-local.txt

It's good that this subject is attracting an I-D.

Perhaps we should first focus on "IPv6 address requirements for networks"
from which we could judge the relative merits and failings of solutions that
meet those requirements - address stability, surviving network disconnection,
renumbering on (re-)connection, etc... for different classes of networks.

Of course, a "Site Locals Considered Harmful" would also be useful (Keith, you 
know it makes sense, and less effort than 100 emails to the list :)

If such opinion can be documented we may save a few hundred emails when
Margaret puts out the call for list consensus (or maybe we won't...)

Tim

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 30 Mar 2003 09:23:13 -0500

>question that was not even on the agenda ...

Actually, Erik objected to calling the question to decide between
the three site-local alternatives ("limited", "exclusive" or
"moderate"). And, in fact, we never called that question...

Discussion continued from that point, including further comments
from Erik.  It became clear that there was significant support
within the group for deprecating site-local addressing altogether,
so we decided to call a different questions -- whether or not to
deprecate site-local addressing.  There was some discussion regarding
the meaning of that question, and people were given an opportunity
to object to the phrasing/timing of the question (none did).

I am sorry that you were ill and unable to attend the meeting and
express your opinion.  I also appreciate your consideration and
concern for the health of others.  But, I believe that you have
a mistaken impression regarding what took place in the IPv6 meeting.

As is true of most IETF minutes, these minutes do not really capture
the discussion very well.  I have heard that there are "movies"
available for multicast sessions, so it is possible that you could
get a better idea of what happened in the meeting by watching the
movie.

There were many people in the room who have traditionally supported
site-local addressing, and about 20 people who stated their opinion
that site-local addresses should not be deprecated.  Those people
have NOT been posting to the IETF list or the IPv6 list indicating
that they feel that the process was used unfairly during the meeting,
or that the results did not represent the consensus of the room.
In fact, a few of them have written and said that they disagreed
with the decision, but that they support the consensus of the WG.
Please think about that.

I also strongly object to your poor characterization of the IPv6
WG attendees.  There were many people in the room who write
"real" implementations and/or run "real" networks, and there
were experts present from many different IETF areas that could be
affected by site-local addressing (most notably routing, DNS,
and applications).

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 30 Mar 2003 09:47:44 -0500

>know it makes sense, and less effort than 100 emails to the list :)

I agree that such a document would be useful.  I doubt, though, that
it will prevent 100's of e-mails to the list -- I've just become
resigned to spending ~45 minutes a day reading e-mail on the IPv6
list...

As part of deprecating site-local addressing, we agreed in the
meeting that, in addition to deprecating site-local addressing in
the addressing architecture and removing it from other places (scoped
addressing architecture, address selection rules, etc.), a document
would be written that would do two things:

         - Explain why site-local addressing was deprecated
         - Outline alternative means to address some of the
                 problems that could have been solved by
                 site-local addressing.

A "site-locals considered harmful" document could be a part of
this document or be referenced from it.

One of the problems of writing such a document is that "site-locals"
are a moving target.  We have (at least) five different proposals on
the table for site-local address "usage" (only four of which are
documented), and most of those proposals can be modified by one or
more of the proposals to create "unique" site-local addresses.

I attempted to capture the issues associated with site-local
addressing in my site-local impact draft:

http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.txt

This document specifically addresses the benefits and issues
associated with the "full" site-local model currently documented
in the scoped addressing architecture WG I-D.  I did not consider
other models, because at the time this document was written, the
"full" model was the only documented model...  A subset of these
benefits and issues exists for each of the less complete site-local
usage models.

Bob and I attempted to capture, in our IPv6 WG presentation, the
benefits and issues associated with each of the three usage models
we presented -- "limited", "exclusive" and "moderate".  We focused
on the differences between those three approaches -- mainly
whether or not they require split DNS and whether or not they
require address selection logic in applications that pass addresses
to other nodes.

I don't believe that our presentation is on the minutes site yet,
but it can be found at:

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

It might serve as useful input for a "considered harmful" document,
or for an attempt to explain the decision to deprecate site locals.

Margaret

---

From: Markku Savela <[email-masked]>
Date: Sun, 30 Mar 2003 18:24:20 +0300

> http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.txt

In above document...
   ---
   3.1 The Fundamental Issue
   ...
         - The addresses are unreachable outside of their original
           context.
   ...
   ---

Some may think the above is actually a benefit: all those
organizations using the IPv4 private address spaces will want
equivalent IPv6 space.

They don't use the IPv4 private address space because of the address
shortage. They use them exactly because those addressess cannot be
used to communicate directly with outside internet. They are not
NAT:ed.

Millions of hosts inside corporate networks have only one address: the
private IPv4 address.

Even if IPv6 is enabled, the system administrator WILL not give global
addresses to the internal nodes anyways. If site locals are not
available, they invent something else for the purpose.

The problem of address selection is red herring. In most cases, where
site locals would be employed, the nodes would still have only one
address: the site local address. Only some special nodes at the edges
of the networks would need to deal with both global and site local.

Using IPv4 private addresses as 6to4 addresses for the purpose is a
hack. What is the point? Non-routable is non-routable. I definitely
prefer a clean FEC0:: prefix for the purpose, instead of multiple 6to4
prefixes.
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Mar 2003 10:08:08 +0200

Markku Savela wrote:

...
> available, they invent something else for the purpose.

Access control lists in routers were in use for this years before
RFC 1597. Preventing unwanted access has never been a valid
argument for private addresses and never will be.

    Brian

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 31 Mar 2003 09:21:36 -0800

Brian E Carpenter wrote:
> Access control lists in routers were in use for this years 
> before RFC 1597. Preventing unwanted access has never been a 
> valid argument for private addresses and never will be.

Let's try to be very crisp with the terms we are using. Private
addresses are exactly about preventing unwanted access. I believe your
intent was to say they are not an argument for ambiguous addresses. 

In the case of self controlled filters I would agree that the ambiguity
of the address is of limited value. In the case where a third party is
also responsible for some of that filtering, there is value in having
the world know to also filter.

Tony

---

From: Alex Conta <[email-masked]>
Date: Mon, 31 Mar 2003 20:33:32 -0800

Tony,

Tony Hain wrote:
> [...]
> the decision was
> based on fear of NAT [...]
>  Local

This is a good point. 

Regards,
Alex