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 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 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
