Subject: draft-hain-templin-ipv6-localcomm-03 comments

From: Pekka Savola <[email-masked]>
Date: Sat, 15 Nov 2003 14:28:01 +0200 (EET)

Hi,

well, the document seems like to completely concentrate on an
addressing-based solution model.. which it probably should not.  Anyone
even glancing at the document can be 100% sure of this.

Or was it only supposed to be agnostic of whether local-use addressing was
needed?  There's a difference there..

So, I agree 100% with Erik's earlier comments on the "coloring" and the 
"background" of the document..

(I only read the beginning of the draft, got too big a headache..)

substantial
-----------

1) the whole section 3.2 Maintaining Confidentiality of the Address Space is
pretty much bogus.  Remember, we're talking about using local communications
with *IPv6*.  With IPv4, you would be required to record the address
prefixes in the RIR registries etc. -- but these are no longer relevant. 
You get one /48, put it in the registry, that's it.  No exposing needed.

Beyond that, all the exposing you'd do is what you choose to do yourself. 
If you don't want to give e.g. people the ability to traceroute through the
network to learn the network properties, you can prevent that.

In summary, this whole section should be removed or seriously reworded.

2) I don't see the point of section 3.3 myself:

   Test networks are frequently large, elaborate networks with a mix of
   public and private address space. Use of random unallocated space
   runs the risk of collision with legitimate addresses on remote
   networks if the test network is ever connected to the Internet.

==> what kind of test network are you talking about?  
why would you ever connect a test to the Internet, except through some DMZ
hosts/routers etc?   

With IPv6, you have enough addresses to play around if you want to connect
something to the net.  If you don't, you can just invent something (most TAC
etc. labs probably certaintly do).  No magic there...

Needs rewording to bring up the point better or remove..

3) there is solutionism/assuming the addressing is the answer in many of the
goal sections, like 3.4, 3.6, 3.6.2, 3.6.3, 3.7, 3.8.  Intentional?

4) section 3.6.2 is just section 3.5 again (note it says Section 3.2 in the
text), could be removed ?

5) section 3.7 is a bit incomprehensible:

3.7 Asset Protection in Enterprise Networks

   Enterprise networks that protect private corporate assets (e.g.,
   printers, faxes, robotics, sensors, etc.) require an addressing
   scheme that remains stable even when VPN connections from outside
   sites occur.

==> how on earth would VPN connections from outside disturb a stable
addressing scheme?!?

6) it's no surprise that section 4 on goals presupposes an addressing-based
solution.  Is this intentional?  In any case, the titles are:

4.1 Easy to Acquire
4.2 Stable
4.3 Multiple Link Support
4.4 Prefix Filtering and Hints to Applications
4.5 Globally Unique
4.6 Usable in the Absence of a Provider
4.7 Applicable in Managed/Unmanaged Environments
4.8 Compatible with Site Naming System
4.9 Compatible with VPN
4.10 Multiple Addressing

one could generalize and reword these to:

4.1 Easy to Take to Use
4.2 Session Stability
4.3 Multiple Link Support
4.4 Application Awareness of Policy
4.5 Locality Between Multiple Sites
4.6 Usable in the Absence of a Provider
4.7 Applicable in Managed/Unmanaged Environments
4.8 Compatible with Site Naming System
4.9 Compatible with VPN (XXX: ?)
4.10 Provision for Both Local and Global Communications

semi-editorial
--------------

Abstract

   The IPv6 addressing architecture specifies global and local-use
   unicast addressing schemes, but provides no operational guidelines
   for their use.

and:

1. Introduction

   The IPv6 addressing architecture [RFC3513] specifies global and
   local-use unicast addresses. Global addresses are understood to have
   unlimited range and may be used as the source and destination
   addresses in packets that originate from any point on the connected
   global IPv6 Internet. Local-use addresses are intended for use only
   within the range of a single link/site, but their specification does
   not address operational considerations for real-world deployment
   scenarios.

==> the critical local-use addressing part is to be removed before this
becomes relevant, so I don't think it's appropriate to refer to these
documents here.  Suggest removing or serious rewording.

....

. As such,
   the address prefixes used in each PAN should be globally unique to
   avoid collisions and provide a means for verifying ownership to
   resolve conflicts.

==> this (in 3.5) doesn't seem to be relevant to the local communications,
remove?

editorial
---------

. Of
   utmost importance is that the systems on board the ship all function,

==> s/Of utmost importance is/It's of utmost importance/

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Templin <[email-masked]>
Date: Mon, 17 Nov 2003 11:50:22 -0800

>"background" of the document..

I'm still waiting to see the specific comments that will correct this
often-expressed wrong impression. Maybe they will appear below;
I'll respond as I go and see where we end up.

>(I only read the beginning of the draft, got too big a headache..)

Take some aspirin, then.

>substantial

I disagree. Network managers should be empowered to self-select
addresses to be used for internal-only communications and with
no pre-arrangement with a RIR. For example, in IPv4 I know that
network 15/8 is owned by HP, network 16/8 is (was?) owned by
Digital Equipment Corporation, etc. But, general knowledge of
this is nothing more than a burden on the party holding the
registration, since they now need to concern themselves with
liabilities for misuse of the RIR prefixes.

In IPv6, there should be no reason for even this level of
exposure if the addresses are indeed to be used only for local
communications. Thus, the ability for network managers to
self-select addresses would be an improvement over the existing
condition for IPv4.

>Needs rewording to bring up the point better or remove..

OK, how about this:

   "Test networks often provide a vehicle for limited experimentation
   with new Internetworking technologies prior to widescale deployment,
   but they may need to connect to the Internet to facilitate the 
experiment.
   Such experiments may entail large, elaborate networks with a mix of
   public and private address space, but the use of random unallocated
   space runs the risk of collision with legitimate addresses on remote
   networks."

But, is this enough to warrant a new document revision? I
don't think so.

>goal sections, like 3.4, 3.6, 3.6.2, 3.6.3, 3.7, 3.8.  Intentional?

Please provide specific examples of text that you believe assumes
a particular solution alternative, since there was no intention to
dictate a particular alternative.

If certain solution alternatives seem to suggest themselves based on
the scenarios, then the document is doing its work - but this is NOT
due to the intentional manipulation of the authors (see changelogs
and acknolwedgements for the substantial community input already
taken).

>text), could be removed ?

This is a valid point, but I prefer to say that sections 3.6.2 and 3.5
could be consolidated rather than removing one or the other. Does
this warrant another revision, though? My take is no.

>==> how on earth would VPN connections from outside disturb a stable

We are talking here about site mergers, which becomes apparent
in the subsequent sentences of that paragraph. When two sites
merge, ongoing local communications  which were in-progress
within the two seperate sites should continue without breaking
when the two sites become one.

The sentences you cite above are taken out of context, and the
meaning seems clear enough when they are considered within
the context of the entire section.

>4.10 Provision for Both Local and Global Communications

One could always re-word, yes, but re-wording can always
be done ad-inifinitum. I don't see anything in any of these
suggestions that provides any beneficial clarification.

>semi-editorial

Update from [RFC3513] to [RFC3513(bis)] you mean?
I don't see this in and of itself necessitating a document
update; in fact, the role of the hain-templin document is
to set the target in motion - not to track the target as it
moves.

>==> this (in 3.5) doesn't seem to be relevant to the local communications,

This goes with the above comment on consolidating sections 3.5
and 3.6.2, but do these alone warrant a new document revision?
My take is that they don't.

>==> s/Of utmost importance is/It's of utmost importance/

Noted.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2003 13:03:55 +0200 (EET)

Hi,

I just about used up all my aspirin and tranquilizers trying to read
this message constructively and trying to write a constructive reply
to this message but failed.

I don't think this document is constructive as a requirements 
document, and I'll strongly oppose it being adopted as WG document 
at any point of time.

---

From: Fred Templin <[email-masked]>
Date: Wed, 19 Nov 2003 09:54:06 -0800

The attitude you're expressing does not seem to be in the
spirit of collaborative discussion, which I find somewhat
unusual and disappointing coming from you. But, if that
is your position you are certainly entitled to it and
I have no problem with it.

Thanks - Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Nov 2003 09:46:15 +0100

Pekka,

I hate NATs, and the delusion that private addresses are a security feature,
as much as you do.

But the problem here is that Tony (author of the strongest NAT critique
issued as an RFC) and Fred are much more in touch with the reality of
corporate network deployment than you seem to be. See for example the
recent messages from Eric Klein. I hear the same thing all the time
from my colleagues in IBM Global Services.

The academic argument that private addressing isn't the answer may be
correct academically, but it has no relevance whatever to getting
IPv6 deployed in the large majority of enterprises that are currently
using RFC 1918 under the collective belief that it's a security feature
(and protects them from the million dollar costs of renumbering).

Now, I would be completely happy for us to throw away the Hain/Templin
draft as long as we immediately standardize the Hinden/Haberman solution.
But if we want to address (pun intended) the problems of the real world,
we cannot ignore the fact that most corporate network managers are
profoundly convinced of the need for private addressing.

We must overcome our cognitive dissonance and simply deal with that
reality. It is the only remaining small hope of avoiding NATv6.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Nov 2003 14:13:40 -0500

> I hate NATs, and the delusion that private addresses are a security 

This draft suffers from many more delusions than that.  If it's going 
to be viable it needs to treat commonly held network managers' beliefs 
as distinct from reality.  I'm all for trying to fashion a message in a 
form that network managers can understand and accept.  But we can't do 
good engineering if we either adopt their delusions or if we pretend 
that non-global addresses should be used in the same way as private 
addresses.

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 24 Nov 2003 12:15:53 -0800

Brian E Carpenter wrote:
> ...

In many cases I would agree with Brian, but in this specific one we have an
example of lost discussion from many years ago about why network managers
'need' a private space, and FEC0 was allocated for it. We need to document
why Hinden/Haberman is needed to solve today's problems, so we don't end up
arguing about it 5 years from now.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Nov 2003 23:44:12 +0200 (EET)

> arguing about it 5 years from now.

If you know the result in advance, why bother to write a 
requirements/goals document?

Wouldn't it just make more sense to just write a document describing 
why private addressing is a good idea (and similarly, say why it is a 
bad idea) ?

The current document, with its broad title, "Goals for Local
Communications within Sites", gives an impression that the document
would be looking neutrally to the real requirements, not presuppose
the solutions.  Even a bare glance at the document shows that there
doesn't even seem to be an attempt to describe the requirements in
terms which are not related to addressing -based solutions.

---

From: Tim Chown <[email-masked]>
Date: Mon, 24 Nov 2003 22:02:24 +0000

> requirements/goals document?

You seem to want such documents a lot when you're wearing your v6ops hat :)

Tim