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