Pekka Savola wrote:
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'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 [EMAIL PROTECTED]
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
