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

[Pekka Savola <pekkas@netcore.fi>]

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.

On Mon, 17 Nov 2003, Fred Templin wrote:
> >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'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
> >-----------
> >
> >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.
> >
> 
> 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.
> 
> >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..
> >
> 
> 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.
> 
> >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?
> >
> 
> 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).
> 
> >4) section 3.6.2 is just section 3.5 again (note it says Section 3.2 in the
> >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.
> 
> >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?!?
> >
> 
> 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.
> 
> >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
> >
> 
> 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
> >--------------
> >
> >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.
> >
> 
> 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.
> 
> >....
> >
> >. 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?
> >
> 
> 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.
> 
> 
> >editorial
> >---------
> >
> >. Of
> >   utmost importance is that the systems on board the ship all function,
> >
> >==> s/Of utmost importance is/It's of utmost importance/
> >
> 
> Noted.
> 
> Fred
> ftemplin@iprg.nokia.com
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 
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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------