Bob: I have read carefully your Unique Local IPv6 Unicast Addresses internet draft, and here are my reactions:
First, as regards IPv6 engineering strategy: the use of non-globally routable, globally unique (or nearly so) PI addresses as proposed in the Local IPv6 addresses ID would alleviate many (but, of course, not quite all) of the difficulties previously identified as arising from use of Site-Local addressing. With the proposed deprecation of Site-Local addressing, a great clamor has arisen for some convention which might provide an improvment over S-L where stable local addressing is required. Your draft seems to define such a convention. While the Local IPv6 addresses proposal does not resolve quite _all_ the issues surrounding address allocations for local environments (more on this below), the current draft nevertheless has much to commend it. In short, I am of the opinion that the mechanisms and practices proposed in INTERNET-DRAFT Unique Local IPv6 Unicast Addresses, or some very similar scheme, should be adopted. Please see below for notes on issues which are likely to continue to fester even after adoption of a scheme such as proposed in the current draft. Now, concerning specific elements of the proposal: Section 3.1 Format The proposals herein are unobjectionable. The suggestion of a /7 space divided into one /8 for local assigns and one /8 for central assigns seems reasonable to me. I am somewhat less sanguine than are you concerning the assumption that the central-assign /8 will never be exhausted, but, as pointed out in the draft, it is possible to augment the space with an additional /7 at some later time if necessary. It might be prudent to ask (or direct) the IANA to reserve another /7 for later use, with the proviso that the additional space will be freed after an agreed length of time if allocation rates prove no higher than expected. After all, the v4 design wallahs didn't think they would exhaust the 32-bit space either. 3.2.1 Centrally Assigned Global IDs I do not see (although I may have overlooked it) any requirement that the allocation authority ensure that a prefix generated in response to a request for a centrally assigned global ID be unique. Since one of the purposes of most central assignment mechanisms is to ensure non-duplication of allocations, it would seem useful to require an allocation authority to enforce uniqueness of assignments which it originates. Although, as pointed out in the text, risk of duplicate assigments is quite low, a simple search of the escrow database or some similar repository of previously assigned values would be, at a minimum, useful; I think it should be required. The imposition of a small, one-time fee for each allocation seems entirely reasonable to me, as does the requirement that allocation requests may be submitted by means other than network facilities, as well as via online access. Although not mentioned (at least to my memory) in the text, good operational practice would militate in favor of an allocation records repository mirrored in at least two widely separated geographic locations, and accessible by wholly independent network paths; however, it is to my mind an open question whether or not we need to specify this level of operational detail in the draft. *.*.* not enumerated above These sections seem entirely unobjectionable, subject to notes below. Additionally, as noted above, the conventions and mechanisms described in the extant draft will not (and, by my reading, do not purport to) resolve all the issues discussed in the IPv6 WG with regard to use of site-local addressing. In my view, additional work, almost all well beyond the scope of said draft, will be required before many of the issues enumerated below are susceptible of resolution. However, the mere fact that the draft is not catholic (note small 'c') in its obviation of problems in no way detracts from the soundness and desirability of the concepts and conventions described in said draft. Specifically, what is proposed in said draft does not: * Drive a stake through the heart of NAT It would appear that the fondest desire of many in the IPv6 WG is to consign NAT to a rapid, and exceeding painful, death. While this may be an admirable goal (for NAT is truly a pernicious beast, and productive of far more trouble than benefit), experience to date seems to show that we will not see the demise of NAT until the designers and admins of user networks have no requirements which can be satisfied by the use of NAT, or have available for each requirement which might be satisfied by a NAT implementation an alternative facility which is functionally markedly superior and administratively much less troublesome than current NAT boxes. However, the provision of globally unique address allocations (if we discount the very low risk of a collision arising from the random prefix generation algorithm) does substantially (perhaps markedly) reduce the number of instances in which NAT implementation is required to handle private implementations which use overlapping address spaces and nevertheless require application-level interoperation for business reasons. This is, ipso facto, a desirable outcome, and IMHO it is not reasonable to expect more of any proposal of the nature of that before us. * Resolve at a single stroke all multihoming issues As pointed out in the text of the draft, unique local unicast addresses may be candidates in some circumstances for use in multihoming implementations. It seems to me most likely that configurations which feature multiple private interconnections between private networks. (NB: for the purposes of this discussion, VPNs, whether operated over pivate links or over the Internet, are considered private interconnections.) The more general cases (specifically, site multihoming and system multihoming over arbitrary transport) are not affected by this set of proposals. Further, I don't know of anything in the multi6 WG which would have direct bearing upon the extant proposal. The availability of stable, unique unicast addressing, even if not globally routable, does enable multihoming over private interconnections using techniques defined by current standards - as far as I can determine, no new protocols or facilities should be required. I see this as sufficient benefit; again, it is not reasonble to expect more of any proposal of the nature of that before us. * Eliminate operational difficulties with DNS and related services regarding destinations which may be reachable only by traffic which originates from a subset of the global set of interfaces or protocol addresses We have recently seen in the IPv6 WG a number of messages suggesting that use of address spaces which are not globally routable and, to some extent, use of scoped addresses, will inevitably give rise to dire consequences in the form of split-face (sometimes called two-face) DNS implementations. Based on experience to date, we are likely to continue to find two-faced DNS implementations as long as we have in user environments addresses which are valid in one or more, but not in _all_, routing contexts. The extant draft does little to alter this situation where v6 is concerned. As pointed out in other messages to the WG, user network administrators, in the absence of permanently stable registered address allocations, are likely to continue to use some form of non-globally-routable space coupled with a set of mechanisms (eg NAT, ALGs, or the like) which enable traffic flow (at least at the application level) from devices on non-routable allocations to devices in globally-routable space. Unless we can persuade user network administrators to use globally-routable addresses for *everything* (see below), split-face DNS implementations may be as persistent and ubiquitous as the common cold. It appears likely, absent a miracle (and I don't have one in my hip pocket this week), that split-face DNS will be a fact of life in the IP world for some time to come. * Obviate all legitimate objections to use of PA addresses in all environments The extant proposal clearly does not address the violent objections voiced by some (in my experience, by many) enterprise network managers to use of PA space throughout enterprise networks. These objections have, at least in summary form, been well aired in the WG; although some WG members have questions the validity of the premises from which the objections are derived, we have not so far succeeded in wishing the objections out of existence. It appears that a fair proportion of small- to medium-size enterprise networks (by my estimate, a majority of those supporting host counts of 30 to about 32,000 interfaces) will continue to object to some of the operational difficulties percieved as arising from exclusive use of PA space in their environments. Unique Local IPv6 Unicast addresses, as proposed in the draft here considered, can, if used in accordance with sound network engineering practice, alleviate some of the more pernicious difficulties perceived by user network administrators. Specifically, these non-globally-routable PI blocks can be used to provide partial immunity of private networks (those which do not require _direct_ access tot he Internet) from forced renumber events triggered by ISP actions or by a change of ISP on the part of the enterprise network administrators. Other benefits, as enumerated in the draft, also obtain. Although, as pointed out immediately above, the Unique Local IPv6 Unicast addresses proposal is not a panacea for all ills of IPv6, it does provide substantial benefit. However, additional work in other areas will be _required_ if we are to have v6 as widely accepted and implemented by the user community as most of us desire. In particular, additional work would be highly desirable (IMO, absoloutely required) on the following matters: * Globally-routable, aggregatable, provider-independent address allocations for use in enterprise and some other types of end-user networks I do not suggest that the use of PA addressing be discontinued; there are substantial numbers of network for which PA blocks are entirely suitable, and for which the PA addressing model may be clearly preferred. However, there is a non-trivial number of networks, as pointed out above, for which the PA model is not well suited; in many of these cases, globally-routable PI space is a superior choice for operational reasons. Granted, this may present scaling problems for extant routing protocols. However, there are a number of aggregation schemes proposed for PI space, some of which seem to have the potential to reduce the prefix count in global routing tables to perhaps managable proportions. Work in this area is not likely to proceed with celerity, much less alacrity. * Renumbering For all v6 networks, a set of tools and techniques is required (IMHO) which will render a renumber event wholly transparent to users and applications (transparent in this context is interpreted as non-service-disrupting with no manual intervention required), and productive of minimal administrative overhead to network engineers, applications administrators, and network managers. Availability of such tools and techniques may encourage some (but clearly not _all_) user network administrators to accept PA allocations, rather than deferring migration to v6 until globally-routable PI space is available, or remaining on v4 'till the proverbial cows come home. We aren't there yet, but there may eventually achieve these goals. My bet it that it will take a while. * Multihoming The multi6 WG has been wrestling with the technical issues for some time now. It seems to me that many of the more intractable issues arise directly from the route aggregation requirements imposed by the current address allocation model, and contents of the multi6 drafts I have read seem to bear this out, as almost every mechanism and protocol proposed has an exclusion clause for large enterprise networks which acquire their own globally-routable (PI) prefixes. * DNS, DHCP, and autoconfig The outstanding issues in these areas have been mentioned in any number of posts to the ipv6 WG; it's not necessary to amplify on what has already been said. OK, now a summary: IMO, draft-hinden-ipv6-global-local-addr-02, while not a panacea for all IPv6 ills, is a sound work which presents a format of local IPv6 addresses which, if implemented in accordance with sound network engineering practice, can be of substantial benefit to end-user networks. The proposals in said draft provide interim relief for several problems identified as being of particular and marked concern to adminstrators of end-user networks in enterprise and some other environments. I am in favor of further work on this proposal, with a view to eventual adoption of this, or similar, facilities. Additionally, this WG, in conjunction with others, should countine to work on other logically distinct issues enumerated above. That's my $.02 worth. AEB -- Alan E. Beard <[EMAIL PROTECTED]> AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
