Brian E Carpenter <[EMAIL PROTECTED]> wrote:
|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.
Feel free to dictate different solutions for the cases of competent
and clueless administration, but please don't assume that you can
equate small with clueless and enterprise with competent--especially
if it will be used as a justification to restrict small networks to,
e.g., dynamic addresses.
|>
|> |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.
The need for stable addresses does not go away just because a site is
connected to the internet. DNS (or similar) will have to be more deeply
integrated than it is now and will have to deal with some sort of push
updates if it is to smooth over the lack of stable addresses.
|> 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;
I didn't say they were trying; I said they are considering it. There
have been messages to that effect on this list in the past few weeks.
We can only hope that they were not totally serious.
|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.
The mantra of scalability is frequently used to justify the status quo of
hierarchical allocation. Unfortunately, it's very difficult to discuss
the issue because there are usually unstated assumptions about retaining
specific aspects of the current routing system.
Several years ago I proposed a system of portable identifiers which will scale
at least as well as the DNS can scale. It was met with similar objections that
we know no other way than ISP-based hierarchical assignment. This is rather
a catch-22: if we never consider any alternatives then indeed we can know no
other way.
|> 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.
It can't be fixed as long as you start with a fixed (no pun intended) number
of bits. You can move the boundaries around and even let them float a little
to make things look less bleak, but it's really hard to beat that exponential.
Talk about a scalability problem...
|> 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).
The problem is that those addresses aren't available to end users, and ISPs
have no obvious incentive to change their current business models. But this
just takes us back to the discussion that you declared was out of the scope
of this list. Since you don't want to pursue the specifics of the business
motivations that are going determine the market we will have to agree to
disagree on the likely outcome.
|> 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.
Generally you can get anything you want if you are willing to pay the market
price. The question is where in the continuum will we end up? I'm predicting
that we will stay near the end where we talk about dollars per address per
month. I suspect you think we will be nearer to the thousands of addresses
per dollar per month mark. Again we will have to agree to disagree since you
don't want to discuss the business aspects.
|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.
Well, I certainly think /48s are applicable, but that begs the question of
how much we will have to pay to get one and how much extra we will have to
pay to not have it renumbered frequently. Make those costs too high and we
are back to NAT.
|> 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,
Specifics?
|but the last
|two sentences are absolutely true.
|> 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.
We live in hope, but most of the proponents seem to have given up.
|> 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.
Umm, I did. Check the archives around 1999.
|And there was certainly no agreement that 8+8 or metro exchanges
|were both technically and economically viable.
There has always been a problem in this respect since some people seem to
believe that the value of portable locators is zero or even negative. This
obviously makes it hard to convince everyone that it is worth even epsilon
cost to implement them.
Dan Lanciani
ddl@danlan.*com
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
