|
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?]
Paul Vixie wrote: (catching up)(you missed some stuff.)On 2004-11-22, at 18.52, Paul Vixie wrote:(let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.)I am not convinced A6/DNAME would have solved all problems, not even all of the ones you pointed out.the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. the DNAME was expected to be inside your own zone. presto, no lock-in. my theory at the time, bitter and twisted i admit, was that we had too many ISP employees in positions of power inside IETF, and that A6/DNAME was seen as shifting too much power to the endsystems. i've since learned that it was just another case of FID (fear, ignorance, and doubt). naturally this presumed that you could add and delete ipv6 supernets from a LAN, which appeared to be the case at that time, though now with dhcp6 and static addressing making a comeback that's no longer clear. in any case there was a need for a TCP option for endpoint-renumber, which was killed in a committee somewhere (i don't know which one, or where or when.) As someone actively working on maintaining an TCP stack (FreeBSD 5.x and 6.x) I can tell you this is a blessing. Throwing more stuff into TCP is only making matter worse and leads to lots of really buggy and non-working implementations. TCP is pretty complex already and only a few people are really up to it. given that ipv6 is now somewhat deployed without rapid renumbering, and that rapid renumbering could have required logic in "both endpoints" of every flow, but that there are now a lot of "other endpoints" without any such logic, it seems to me that MULTI6's only option is to make NAT work, even if you call it "site local addressing" or even "ULA's". (show me.) If you want that, then go for SCTP. And please don't add any more layering violations. It makes implementors life painful and kills any architectual cleaniess in operating systems. -- Andre
|