North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: who gets a /32 [Re: IPV6 renumbering painless?]
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 Attachment:
signature.asc
|