On Mon, 2004-11-22 at 17:52 +0000, Paul Vixie wrote:
none of those three things is acceptable, not even as a compromise.
The current solution I see for this is still IPv6. Except that one moves the complete 'Independence' problem a layer higher. Enter:
HIP: Host Identity Protocol: http://www.ietf.org/html.charters/hip-charter.html
this level of complexity seems a little high for anything to be universal.
It depends all on what one wants, either one gets a lot of routes and thus what we currently have in IPv4 or it is done completely different, like that. As for it not being universal, there are quite a number of working implementation already that seem to be proven to work quite reliable. One of the alternatives of course is something similar as MIPv6 etc.
(let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.)
Wasn't it more because a single A6 lookup could cause one (the resolver that is ;) to have to follow a overly long chain of A6/DNAME chains, which thus could cause maybe somewhat infinite lookups? I rather like DNAME btw: "ip6.int DNAME ip6.arpa", which works quite fine. A6 is fortunately not supported any more by BIND. On Mon, 2004-11-22 at 10:29 -0800, william(at)elan.net wrote:
1. A6/DNAME were great idea, I'm really disappointed they are not going forward...
It is, except maybe for the above noted 'problem'. Most of the time though a site will have only a limited number of DNS servers, thus A6/DNAME would be on the same server and the administrator could IMHO quite easily do the simple replace trick on the configuration.
2. Level of complexity is a very relative thing. To me the important is not to overwhelm any single protocol and allow clear separation between different levels.. In that sense if we actually are able to create new "host identity" layer we can solve the problem with not only dynamicly changing ip addresses but with simplified multihoming for end-user sites.
For most people on this globe the concept of 'IP' or even the phone system is already magic :) Depends on bit who looks at it.
What is bad however is that IETF instead of pursuing it as one effort has several of them including MULTI6, HIP, etc.
The fun of politics ;)
BTW - regarding why these effots while being ip-independet would not work for Ipv6, the reason is addressing. We need new kind of addresses and they all require "id" that TCP can use for establishing connection and that ID can not be limited to 32 bit so we end up considering reusing part of IPv6 space for this new kind of "non-ip" addresses. I think given large amount of available IPv6 space that is acceptable - if we cut the pool to 1/4 we'd still have enough.
No issue there then now is there ;) Greets, Jeroen