Dan Lanciani wrote: > > Quality Quorum <[EMAIL PROTECTED]> wrote: > > |It seems to me that stability and security of internal enterprise > |addressing is a very serious requirement. > > And why just enterprise? The stability of my home network is more important > to me than the stability of any enterprise network.
We can all agree that they are both important. The main difference is that you can expect some degree of expert knowledge from the people managing enterprise networks, but not from those managing home/small office networks. That may be enough to dictate different solutions in the two cases. However, the ability to deploy innovative new end-to-end applications in a truly secure way is also a very serious requirement. In fact, people designing innovative applications (think of Web Services as an example) are trying to design independently of addresses (e.g. by using URIs as identifiers), but we end up with absurd stacks such as SOAP over HTTP over TLS over TCP over NAT over IP, which succeeds in punching straight through the alleged security of NAT as well as the alleged security of firewalls - so all the security has to be done over at the XML level. Pretty silly. If we didn't have to deal with the likely presence of NAT, things would be substantially simpler. > > |Frankly, I do not see any way > |to avoid NAT6. > > Without some other kind of local address space it does seem inevitable. What's inevitable is the need for stable address space when running disconnected, and reliable name-to-locator translation (a.k.a. DNS) when running connected to the Internet. That doesn't make NAT inevitable. > It's > unfortunate that folks are considering ways to make applications NAT-hostile > to force us to depend on global addresses allocated by ISPs. Since we rely on network-level locators as end to end identifiers, end to end applications rely on invariant locators. Nobody is trying to "make" applications NAT-hostile; NATs simply *are* application- hostile, and will be until we find an alternative to using newtork- level locators as identifiers. We've known this for at least 5 years, but haven't found a way out of it yet. Unfortunately, the only scalable way we know to assign locators is to have them assigned hierarchically via the ISPs. Nobody is "considering ways" to force "us" to depend on addresses allocated by ISPs. It's just the mathematics of scalable connectionless routing that got us where we are. > > |Second isssue, which will IMHO force NAT6 is relative scarcity of global > |routing prefixes. In the current scheme of things we have only 25 bits to > |express routing topology (the rest is taken by admin and local) and > |it may prove to be too small. > > Given the hierarchical allocations required by strict address aggregation, > pretty much any fixed number of bits is too few. Hierarchical allocations > are incredibly wasteful because they consume address space exponential in > the number of providers in the chain. They also tend to make the structure > of the market inflexible and require pre-definition of various "types" of > providers--something that would have been better left to that market. That is exactly why the old "TLA/SLA" boundaries defined in RFC 2374 have been dropped, and the registry policy is based on flexible boundaries now. This issue has been fixed. (Of course the /48 and /64 boundaries haven't gone away.) See http://www.ripe.net/ripe/docs/ipv6policy.html and http://www.ripe.net/ripe/docs/ipv6-sparse.html > I > suspect that regardless of the intent, many consumer-level ISPs will operate > at the bottom of the chain (likely below the point that the architecture > considers suitable for ISPs). This will virtually guarantee an artificial > address scarcity at the end-user level. I really can't see why, given the number of /48 prefixes available (35,184,372,088,832 to be precise). > I've noticed that even the optimists > are no longer talking about /48s for dialup. Soon I expect that the reduced > claims of /64s will degenerate into /{128-n}s where n is directly related to > the "level of service." There isn't the slightest reason that /48s shouldn't be provided for dialup, although I will agree that they are likely to have a higher market price than /64s. However, in the context of home networks and small office networks, we should be thinking in terms of always-on connections in any case, where /48s are clearly applicable. > > It's really a shame that IPv6 took the path that it did. Originally it was > to be a clean and simple solution to the address shortage. Fixed-length > addresses and (supposedly initial) hierarchical allocation were virually > mandated by the simplicity requirement. The two alternatives that would > have provided far greater flexibility (*variable*-length hierarchical > addresses or fixed-length portable identifiers) appeared too complicated. > Over the years IPv6 has acquired the every-feature-but-the-kitchen-sink > syndrome, and the relative complexity of a more powerful addressing scheme > looks quite low in retrospect--but now it's too late to retrofit one. At > the same time we are discovering that merely increasing the (fixed) number > of address bits while perpetuating the allocation and routing procedures > that were originally intended as a temporary hack to keep old hardware running > doesn't offer the panacea we expected. The problem was never just (or even > mostly) the number of bits in an address. It was (and is) a complex combination > of techincal routing issues and market economics. There is considerable historical inaccuracy in this paragraph, but the last two sentences are absolutely true. > > |I hope that by addressing this problem head on early in the process we can > |do implementations much less painful and better prerforming. > > The problem was addressed early on with site-locals, but now they are being > restricted into uselessness. Well, we haven't changed a thing in the standard yet, and we still seem to be debating the question. > I have strong doubts that the discussion of > globally unique identifiers is anything more than a passing diversion. Every > time this has been discussed in the past it was shot down on the grounds that > it could subvert the all-important MLM^H^H^H hierarchical addressing scheme. The reason we have never made any progress is that nobody has come up with a suggestion (except 8+8 or metro exchanges) on how we can reconcile provider-independent locators with route aggregation. And there was certainly no agreement that 8+8 or metro exchanges were both technically and economically viable. Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
