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