Kurtis: Thanks for your thoughtful response. I'll reply to your queries inline.
AEB On Fri, 14 Feb 2003, Kurt Erik Lindqvist wrote: > > Most end-user network managers I deal with require these > > characteristics > > of their public network address allocations: > > > > 1) uniqueness (sometimes expressed as "autonomy") > > Wait. This is interesting. From what people here was saying before - I > drew the conclusion that end-users wanted non-uniqueness aka > site-locals to hide their topology. You are saying something else? > Please note the keyword "public" in the statement above. This applies (in the cases of most of my clients) to address spaces which are advertised to the public networks (AKA The Internet). Now, in answer to your implied question about addressing for private (internal) networks: Given the choice, most (in fact, nearly all) of my clients would prefer to run their internal networks on registered, unique, globally routable address space; this greatly simplifies the task of providing access to resources on the public network, and of providing access from the public networks to resouces which the external customers of the business desire to use, usually with the result of generating revenue for the business. Furthermore, the use of unique, globally routable address space vastly simplifies the task of establishing connections to networks operated by business partners (eg, vendors and larger customers), whether via the public network or over private links. However, my clients are wholly unwilling to run even the slightest risk of a forced renumbering on their internal networks. Full stop. No exceptions, and no equivocations. If unique and stable globally routable space is not available for use in their internal networks, my clients see non-unique, globally non-routable space, coupled with NAT, as a feasible (but not desirable) alternative: at least they have a reasonable expectation that such addressing will be stable, and that a forced renumbering is unlikely. For IPv6, the site local space meets the requirement for internal networks of address stability. That the SL (or, for IPv4, PNN) space is globally non-routable mitigates somewhat the inconvenience of maintaining NAT: if you use application-level gateways in addition to NAT, the ACLs can be less complex (although not less carefully crafted) than otherwise. With such an implementation, it becomes relatively straightforward to obscure the details of internal network structure (at least from the standpoint of the public networks) since neither the prefix nor the internal structure is advertised beyond the local environment. And yes, these clients do realise that the above steps are not alone sufficient to forestall intrusion or other malicious acts. > > 2) portability > > I can see that. > > > 3) stability > > Do you mean as a derivate of portability or for some other reason? > No. The stability requirement is quite independent of portability. My clients desire to avoid renumbering at any cost short of summary hanging; where it is not posiible to avoid renumbering, they wish to renumber as few systems as possible, and they would much rather change a static translation mapping than reconfigure a host. Where these clients are forced into renumbering (say, when they have to change ISPs as a result of poor service), they are vastly dissatisfied and profoundly resentful. For public network address spaces, portability is an aid in achieving stability, but hosts will have stable numbering even if the public network addressing is neither portable or stable. I think that the prevailing opinion in this WG has been that the situation described above (at least, the worst-case configuration) is not desirable. > > In many cases, requirement two is driven by a desire to implement > > multiple connections to the public networks via more than one service > > provider (multihoming). > > > So by portability you mean the ability to have a prefix announcement > accepted by multiple providers. > No, although that is one element. The specific meaning attached to "portable" by most of my clients is this: "when I discontinue service with any ISP (actually, Internet Access Provider, as most of my clients maintain the services - that is, hosts and applications, including DNS and SMTP - inhouse), the addressing of my hosts as seen from the public networks remains with me. Furthermore, I can advertise the (usually native) addresses of my hosts via any combination of access providers willing to carry the traffic and provide transit routing." > > While PI is not an absolute requirement, the present state of our > > > > The above properties of a prefix is not the same as PI, as well as PI > properties are not the same as above. For both IPv4 and IPv6. > > > technology and standards (for v6 as well as v4) force us to PI as the > > only > > implemented mechanism which satisfies the functional requirements > > enumerated above. If we can develop and write into the standards some > > (Someone could say NAT and SL but I am glad you didn't) Agreed. > Well, NAT and SL will work (even if administratively proscribed), although at undesirably high administrative cost, if no better solution is available. However, my clients won't be content with NAT and SL, even if they see it as the least distasteful option open to them. > > For those end-user-network managers who are aware of the details of the > > NREN allocations, this situation provokes pure, incandescent fury: the > > academic entities are seen as having been granted special (and grossly > > preferential) treatment, while the commercial (as distinguished from > > service-provider) networks are subject to callous indifference and > > excluded thereby from direct access to stable network address > > allocations. > > We can't even claim "separate but equal" for this state of affairs, and > > the universal principle of Brown V. Board of Education still holds, > > even > > for networks. [For those not familiar with recent US history, send me > > mail > > directly for a brief explanation of the above reference. AEB] > > I am not familiar with the above, but I generally tend to agree that > NREN and other networks are far different. For good and bad. > I agree that NREN networks differ from other networks, but it does not follow that other networks should thereby be forced to discriminatory treatment while NREN networks obtain top-quality service. (BTW, Brown v. Board is a 1950s US Supreme Court ruling which held that, in the provision of services - in this case, public education - separate facilities or service models for different groups are inherently unequal. Furthermore, the Court held that, in this context, unequal == discriminatory. This is considered a landmark ruling in the area of civil rights law.) > > Most of the end-user-network managers among my clients now multihome, > > and > > will continue to require multihomed service in future. In every case > > where the user's network is multihomed, the multiple independent > > connections are seen as crucial for maintenance of high availability of > > I find this funny. A number of studies have shown that if this is what > you are after, multihoming and BGP is the wrong way to go - but never > mind. > Your comment may be true, but my clients are nonetheless unwilling to risk the possibility of an extended network outage on a single ISP (while not frequent, these events are far from unprecedented) rendering their online customer-support environment unavailable for several hours, much less for a day. Shorter outages (on the order of minutes in the single digits) are tolerated, provided that such outages are infrequent. > > the client's services to the public networks; and high availability is > > considered an absolute requirement for survival of the business. In > > some > > cases there are regulatory requirements which can result in civil or > > administrative sanctions (including, in the worst event, loss of > > operating > > licenses) if the services should be found unavailable for significant > > periods of time. Yes, it is possible, at least in theory, for > > commercial > > service providers to sustain the required level of availability, but > > most > > of my clients have found, much to their distress, that the US ISPs are > > almost uniformly incapable of doing so in practice. In almost every > > case, > > the administrative managers for these user networks are simply and > > flatly > > unwilling to put their businesses at the mercy of a single ISP. > > This worries me but is more a topic of Nanog, or my planned > presentation at the Barcelona RIPE rather than IPng. > This should worry all of us if we are determined to require PA as the default allocation model for IPv6. And I will suggest that this is properly a topic for the IPv6 working group: have a look at the charter. > > Based on conversations with my clients, I cannot find it within the > > scope > > of my imagination (or, for that matter, of theirs) that these networks > > will give up the mutilhoming requirement at any time within the > > foreseeable future. > > Hmm. So if someone where to write up a draft on how to do resilient > routing, with different alternatives and pros and cons, could you take > this to your customers? Randy, is this something to add to the > Barcelona topics? I think I have some slides to start this off....(now > all we need is a logo and we have a project) > Yes. However, I must caution you that resilient routing alone will not resolve the objections of most of my clients to IPv6 as presently managed; it merely removes one item from the washing bill. > > Home networks may be another matter, but I would give my eyeteeth to > > get a > > stable, portable (and, thereby, multihome-capable) IPv6 allocation for > > _my_ home network, as that network also supports supports my office and > > Notice that this comes at a price. You and me are willing to pay for > this, but how many are? > > > suspect that we will find increasing use of "home" networks for > > business > > activity, and increasing demand for stability of network locator > > Sure, but are you willing to pay for it? > Yup. But willingness to pay is moot if the service can't be had due to administrative fiat. (This comment is in the business-network context.) > > can't multihome. Based on experience with my client base, I cannot > > agree > > with the postulate that many networks will not find lack of multihome > > support a barrier to implementation of v6. > > I agree. Your client base seems to be exactly the target group. > However, they also seems to be willing to pay for the service, as > otherwise they will suffer financial loss that is higher than a days > salary (if you can't log in from your home network). > I suggest further that these issues extend far beyond my client base; in fact, to most businesses that rely in whole or in part on online systems (those accessible from the public networks) for all or a substantial part of their revenue. The number of such busineses is growing, and I would prefer that it continue to do so. Under the current IPv6 allocation practices, most of my clients can't get PI space, even if they were willing to pay unlimited fees, since most of the groups are not multi-national is scope. (In many cases, these businesses hold state or national charters which explicitly forbid interoperation with foreign businesses of the same type. Please note that foreign transactions are not prohibited, but sharing of operational facilities - including networks - _is_ expressly forbidden. At a minimum, a Chinese wall - i.e. firewalls and separate routing domains - is required to satisfy the audit requirements.) > > The current speculation about "what the users _really_ need" (as > > distinguished from what they _say_ they need) smacks to me of "all > > networks are equal, but some are more equal than others" (with > > apologies > > to _Animal Farm_). It seems to me that we have some technical > > problems > > Agreed. > > - kurtis - > > I hope the above has clarified (or at least disambiguated) some of my statements in the original note. Regards, 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] --------------------------------------------------------------------
