Robert Elz <[EMAIL PROTECTED]> wrote:
| | Anyone who currently
| | owns portable IPv4 address space isn't going to give it up without a fight.
|
|No, but that isn't v6 address space, so it isn't really relevant to the
|immediate issue.
It's relevant unless you eliminate 6to4 and any other scheme that generates
portable v6 address space from v4 space. 6to4 is actually rather interesting
in that it has the potential to overtake "native" v6 addressing (especially
considering Microsoft's treatment of 6to4 as a first-class citizen). Once 6to4
has served its purpose of jump-starting IPv6 deployment and the time comes to
kill it off in favor of native aggregated addressing, the task may be more
difficult than was anticipated. If the bulk of users are on the 6to4 side,
simply severing ties to the native backbone won't do the trick since that would
hurt the native users more than the 6to4 users. It would instead require action
on the v4 backbone to block the encapsulated 6to4 traffic, and that might raise
some eyebrows.
| | This is not progress. Router renumbering gives ISPs a tool to conveniently
| | change your addresses out from under you if you haven't paid a premium for
| | stable address space.
|
|I don't think I'd quite go that far - it gives me a tool to help me
|renumber my site a little easier if that is forced upon me (for whatever
|reason). I don't think it quite allows an ISP to do that without my
|consent. But maybe I missed something in the RFC?
I can't imagine how an ISP would need your consent to renumber. Unless you
mean this in the trivial sense that the ISP can't force you to change your
numbers beyond making those numbers no longer work...
| | Real progress
| | would mean solving the much harder end-node renumbering problem with all
| | that entails at the protocol and application level.
|
|Certainly. But this may be an issue where real progress is built of
|a very large number of very tiny steps, rather any any single quantum leap
|forward.
Clearly we disagree on this point. Since there is no overview of the solution
that is to evolve from the current approach, there is no reason to believe that
these particular tiny steps are actually moving in the right direction. They
may appear to "solve" in some sense some aspect of the problem, but we may find
that a complete solution at best subsumes the partial solutions (leaving a lot
of legacy warts) or at worst is incompatible with existing deployment.
| | This is the model that ISPs are promoting. If you want to do anything
| | interesting you need static address space, and you are going to pay for it.
| | (Of course, you have to beg for the privilege of paying for it and it still
| | isn't portable.)
|
|Yes, I can see that as an attractive model for some people.
Yes, well, umm, it's an attractive model for the people selling the addresses
and an unattractive one for those who are paying.
|Personally, if
|we can make renumbering work well enough, then I don't think I'll care if
|my address changes every now and again.
If renumbering could be made totally transparent then stable addresses would
no longer have value and we wouldn't have to pay for them. But that would
upset the current status quo so it isn't going to happen.
|But I suspect you're also thinking of the "I am going to stop you running
|a server" mentality of some ISPs
I'm thinking of the ``we are going to charge for anything we can even if it has
no marginal cost to us... just like phone companies'' mentality of some ISPs.
|- the dhcp lists get questions from them
|along the lines of "how to I force (dhcp) clients to give up their old address
|and get a new (different) one every few hours?" That's for exactly that
|purpose.
And the tcp-ip protocol lists get questions from them along the lines of,
``how do we detect and stop NAT activity.''
|Of course, this is because they're designing a service, and
|supplying bandwidth, and then charging the customers, based upon the
|assumption that they're a (current) "typical home user" - ie: someone who
|sends and gets a bit of e-mail, and browses the web a bit. The e-mail is
|insignificant and irrelevant in the grand scheme of things, and the web
|browsing all just bangs on the local proxy cache. Hence cheap rates
|are possible.
It's more difficult to build a service where they sell bandwidth so they sell
addresses instead. This thinking is not going to change with IPv6. And the
thinking is applied to business accounts as well, so the "typical home user"
part is questionable.
|But none of that really has much to do with renumbering ease, or IPv6.
It does in the general sense of whether IPv6 will cater to the ISP's needs
or to the customer's needs. More importantly, it does in the sense of making
IPv6 an attractive replacement for NAT. One of the big pitches for IPv6
was that it would solve the address space problem, eliminate all that nasty
NAT activity, and restore the purity of end-to-end connectivity. But since
the ISP business model is based on scarce/expensive address space, the end
user will not see the promised change. With no obvious benefit and a high
transition cost, IPv6 will not be an easy sell.
|That kind of ISP meets a need in society, and I expect will continue to
|exist. There are other ISPs around (often charging more, as you'd
|expect) who don't do this kind of thing. And as you point out, often
|ISPs run both kinds of service - you pay more you can have a stable address
|(ie: you can run a server), you pay less, and you can't.
|
|I don't think we should dwell on those issues - you're not going to get
|a stable address for the cheap (no server) service if the ISP can find any
|way to cause it to vary, no matter how easy or hard renumbering is, as it
|isn't address stability that is the issue/problem there - it is traffic.
Why not dwell on the issue (or the issue of multi-homing for which you should
clearly pay even more--at least according to the ISP business model)? We could
fix the model so that ISPs wouldn't easily be able to use these particular
games in place of bandwidth management and we could then provide end users with
some real advantage to entice them to IPv6.
| | People recognize that at some level you need an identifier that you can
| | call your own. At the moment, the DNS doesn't quite do it.
|
|Then let's make it, as much as is reasonable.
Again, IMHO, this is a case where a partial solution is worse than no solution.
It discourages work on a real solution by making it appear less urgent.
|Personally I don't think
|it will work well as a connection identifier (though people have proposed
|using DNS names for that),
I don't think it will work well either, though mainly because of historical
API usage and fixed-length packet thinking. However, the problem can be
solved easily with a fixed-length identifier that is looked up in much the
same way as a DNS name. In other words I agree that a level of indirection
is a solution, but A6 is the wrong place for it.
| | A few years ago I proposed a portable identifier mechanism
|
|There have been many of those over the years - look in the big-internet
|archives for all the discussions on EIDs.
Yes, as I said when I made the proposal, the notion is not original. But the
version I proposed is a relatively simple retrofit into IPv6 even at this late
stage.
|It would certainly be an
|attractive thing to do, but there are undoubtably also problems that need
|to be solved to make them practical.
Well, the folks who patented (a version of) the idea don't seem to think there
are any significant problems with their implementation. In any case, the
problems are no worse (scope-wise) than the DNS problem. Yet once the problems
are solved, the approach takes care of renumbering, multi-homing, and mobility.
There would be no need to go on looking for little pieces of the problem to work
on over the years because it would all be solved. I'm puzzled why people think
it's a good idea to expend time and effort on something like A6 which might,
someday, in conjunction with some other as-yet-unidentified things help with the
renumbering problem yet a comprehensive solution (which has now been implemented
and patented) is consistently rejected because it might require a little work.
| | This is true but misleading. It is misleading because of the unstated
| | implication that the problem can't be solved by throwing bigger hardware
| | at it, and this is still open to debate.
|
|Yes. And while it is true that hardware has been keeping up with the
|current growth, it is also true that current growth has been constrained
|heavily - I'm not sure that even the best we could do with hardware now
|would manage to cope with what the tables would look like if everyone with
|an internet connection owned their own stable address (the way we used to).
Let's pretend that we didn't have aggregation now. In fact, let's pretend
that we did just the opposite and split up all those class-B and class-A
networks into class-Cs (if only to make the worst-case math easier). That's
2^24 routing table entries. We want a fast forwarding operation, so let's use
a direct lookup table of 4-byte pointers to some sort of interface structure.
That's 2^26 bytes = 64MB. My old palmtop has 64MB. My friend's old laptop
has close to 1GB. Naturally, I wouldn't suggest trying to populate that table
using BGP...
| | And we could improve the routing protocols.
|
|Yes. But to date we haven't.
Plenty of research has been done, but it doesn't seem to get applied to
the real world.
| | Back when address aggregation was introduced for IPv4 it was billed as
| | temporary hack to slow the growth of the routing tables until hardware
| | had caught up. CIDR block addresses were _not_ supposed to be non-portable.
|
|yes. I know. I recall the promises that that would never happen.
Much like the current promises of IPv6 to provide a good replacement for
NAT'ed addresses...
| | Rather than attempt to solve the routing problem, IPv6 as currently
| | envisioned simply redefines the temporary hack as a feature of the
| | routing architecture.
|
|Yes. That's absolutely true. But it isn't a design aim of IPv6
|to do that,
Could have fooled me...
|it is just that no-one has yet proposed any other good
|solution to the routing problem.
My proposal was apparently good enough for the companies who applied
for the patent (at least according to their posting to this list they
applied). I just wish they had referred to my prior art...
| | It expands the address space bit-wise, but preserves the economics
| | of address allocation.
|
|I know what you mean (given the context) - but that isn't quite true.
|There's another issue here that does change, radically. With IPv4
|you not only pay for stable addresses if you want them (really for the
|ability to run a server) and even more for portable addresses - but you
|also pay for the number of addresses you want allocated. The last of
|those will vanish with v6 - there's simply no rational way for an address
|block smaller than 2^64 (other than perhaps 1) to be allocated.
Don't count on it. The ISPs will simply filter out all but the number of
addresses that you have paid for. They won't care if they are wasting
(2^64 - [number of paid-for addresses]) per customer. The big advantage
(to ISPs) of IPv6 over NAT is that they can do this automatically. With
NAT they have to use fairly subtle algorithms to try to detect and block
"extra" hosts--so subtle in fact that it isn't really practical. With
IPv6 all they have to do is populate a table with the first n 64-bit IDs
and block any others. Perhaps if they are nice they will clear the table
periodically so you can move IDs around. (Don't expect to be able to use
rolling IDs for privacy.) If they are less nice they will tell you which
IDs you can use.
|But that doesn't mean that someone can't
|go and make all of this work redundant by figuring out some smart way to
|route to billions (of billions) (like 2^48 at least, 2^64 potentially)
|individual addresses with no topological significance at all. If there's
|someone out there with the solution all ready just waiting, then please,
|let us know (even patent it, and then let us know).
Discussions of the addressing issue always seem to end up here. It reminds
me of an episode of the Simpsons where the father keeps saying, ``I'd like
to do something, but there is nothing I can do'' while the daughter keeps
telling him about the easy thing he could do...
Others have presented solutions. I have presented a solution. A version of
my solution has been patented unfortunately (or at least the companies claim
to have applied for a patent). If anyone were serious about implementing a
solution I'd be happy to argue prior art to invalidate the patent.
I understand why you feel that it is necessary for packets to carry routing
hints (and that's exactly what topological addresses are--routing information).
As you said, FUD works, and a distributed routing model might be too radical
a departure from existing practice to be easily accepted at this time. However,
we do not have to foist these routing hints off on the end user as addresses.
A portable identifier that is independent of the topological address solves a
variety of problems. At some level the result must be isomorphic to distributed
routing, but the extra level of indirection allows the solution to be more
clearly visualized. And perhaps that's the important thing as far as FUD goes.
| | Of course NAT will be used with IPv6. Why pay a per-address fee and then
| | an additional fee to keep the address stable (at least in the short term)
| | when you can maintain your own internal addresses with NAT?
|
|The "keep the address stable" part isn't helped at all by NAT.
Sure it is. Sites care about internal stability as well as external. Site
local addresses are yet another IPv6 hack that recognizes this fact and tries
to partially mask the problem.
|The
|only advantage to stable addresses (aside from the problem of renumbering
|your site) is where it is known to others.
So you are saying that the only advantage of stable addresses (aside from
internal use) is external use. Yes, I agree. :)
|For most sites renumbering internally is already cheap -
You must be very lucky; I have yet to encounter such a site.
Dan Lanciani
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
