"Tony Hain" <[EMAIL PROTECTED]> wrote:
|I do have one question about your comment, do you believe transparent
|renumbering is a sham, or did I mis-read your intent?
I don't believe that transparent renumbering in and of itself is a sham. I
do believe that any claim that it will be implemented soon enough and well
enough to obviate the need for stable local addresses is a sham. I also believe
that the claim that transparent renumbering is an easier problem to solve than
portable identifiers is a sham. IMHO, the easiest way to make transparent
renumbering work is to introduce a level of indirection. But that's really
just the same thing as having portable identifiers. Any other solution to
the transparent renumbering problem is going to involve pervasive changes at
all levels of the stack, and APIs to put applications in the loop. In other
words, it can be at best transparent to the user. This is a lot of work.
|Your point is there will be end-user-controlled address space, the only
|option we have now is SL but we only need one mechanism that meets the
|requirement.
I certainly wouldn't object to having more than one mechanism. My concern is
that if we keep waiting for a better solution we will have no solution and
NAT will prevail. I don't see any benefit of NAT'ed v6 over NAT'ed v4, so why
bother to change at all?
Something else that bothers me about this discussion is that while there is
endless debate around such relatively subjective (and thus highly debatable)
topics as the potential security benefits of site-locals, I have yet to see
anyone directly address basic questions like:
How do I talk to my local network pinter without renting an additional address
from my ISP? If I rent another address for my local file server, how much
extra do I have to pay to guarantee that it won't be renumbered in the middle
of a six-hour build? Clearly since I'm doing builds and using a file server at
all I must have a profitable business, so the ISP will be justified in demanding
that I buy at least their ``small business package'' to get such a ``feature,''
no?
There have been several vague hints that v6 has offered up a solution to v4's
(arguably artificial) address shortage, but I've yet to see anything tangible.
In fact, v6's renumbering support makes the situation that much worse for end
users in as much as it goes way beyond DHCP in giving ISPs the ability to
disrupt a network. Remember that--with a few exceptions--ISPs are in business
to make money. Counting or limiting addresses (and in particular, stable
addresses) as a surrogate measure of bandwidth is a very popular business model.
I've heard absolutely nothing to convince me that the business model will change
with v6. From those that claim that global v6 address space will be cheap and
easy to get I would like to hear specific details of the new business model that
ISPs are preparing to adopt.
|> So we are coming full circle? We have the renumbering
|> problem because the portable address/identifier problem was
|> declared by fiat to be too hard to even think about solving.
|> We are stuck with site-local addressing because the
|> renumbering problem turned out to be too difficult to solve
|> in practice.
|
|Please explain... I understand that renumbering and static configuration
|of things like filters can be a challenge, but those are solvable given
|a reasonable time period. Is this simply a matter of an app can't
|survive a reunmbering event?
For anything other than the indirection solution, I'm afraid applications
are going to have to be involved in renumbering. Nobody seems to be working
actively on this anymore, so the time period may well be infinite. In fact,
I think I've seen comments in this thread that applications should not be
expected to deal with frequent renumbering. Since it isn't clear that dealing
with one renumbering event at a bad time is any easier than dealing with
frequent renumbering events, I think this is just a euphemism for saying that
it's ok for applications to fail in the face of renumbering. As long as the
renumbering is infrequent users are supposed to accept such infrequent failures
from the applications. Of course, there is no reason to believe that those
renumbering events and failures will be infrequent in real life. If applications
deal with neither scopes nor renumbering we are back to NAT again.
|This is because there is a complete lack of appreciation for the
|fundemental requirement that a network manager have stable locally
|controlled address space.
This has bugged me for years. Being a cynic, I have to think that at least
some factions appreciate the requirement and look to an artificial shortage
of such address space with a profit motive. But once again, we know that
trying to extract too much money this way simply fuels NAT usage. Even if
v6 is more hostile towards NAT implementation, there are some pretty clever
authors out there...
|As a slightly off topic question, do you agree with the business driver
|assertions in draft-hain-ipv6-pi-addr-use-03.txt ? We can disagree about
|the approach in the PI format, but the fundamental reasons should be
|consistent.
I'm not sure I understand the question. What is the business aspect? I
have nothing in particular against geographic addresses, especially if
they are the only kind of routable "portable" addresses I can get. The
big questions will be whether ISPs feel they can charge a premium for
supporting such addresses and whether there will be some other entity
who will want to collect a (possibly recurring) fee to allocate them in
the first place. (Granted the latter will seem a bit funny. Why should I
have to pay to allocate address space defined by the land I own? But weirder
things have happened.) I did notice some wording in your draft that implied
a need-based usage, e.g., for multi-homed customers. I hope there will be
nothing to allow ISPs to classify such addresses as a premium service because
of their association with what are perceived to be activities limited to
big/rich companies.
|Non-routable global addresses are by definition local. The only thing
|they bring to the table over SL is ambiguity in the scope of
|routability.
They may help with site merger. My only point is that they don't remove the
need to deal with scopes, so they aren't in any sense an alternative--just a
variation. Thus the argument that we don't have to worry about scopes if we
wait for non-routable globals seems specious.
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]
--------------------------------------------------------------------
