* Owen DeLong <owen@delong.com> [2004-11-28 19:51]:
there are a lot of organizations now having PI without having an ASN and beeing multihomed. a transition to v6 with this policy would make things much worse for them, so why should they? They shouldn't unless they need features that are available in v6 that are not available in v4. Where's the harm in this? The v6 stack provides for encapsulating v4 addresses in v6 easily enough and the v6 specs already make allowance for this. I don't see any reason we need to get such a site over to v6.
ehm the v4-in-v6 mapping is a gigantic security issue. this is nothing but establishing tunnels automagically and extremely dangerous. v4-in-v6 is not supported on purpose or at least disabled by default on many OSes, and that is a good thing. so you say they should just keep v4 - that does not really help in getting v6 deployed.
on the other hand, 1 ASN -> 1 v6 prefix does not necessarily mean 1 v6 prefix -> 1 ASN. might work out While I think a policy of "If you qualify for an ASN, you qualify for a prefix" makes sense, I do not think that the reverse makes any sense whatsoever.
ack.
The convenience factor _is_ already outlawed. true for new allocations, but there is a gigantic installed base, and making their situation worse isn't exactly helping in getting v6 deployed. As near as I can tell, there's very little reason for such a site to ever adopt v6 and very little reason for the world to care that they didn't.
i think there's many many many more of those sites than you think. and we really don't want to run in two parallel universes for longer than it has to be...
As such, I'm not sure I understand why this is a significant issue. Is there some reason it's important for these sites to go to v6 instead of using 4-to-6 address encapsulation at their border?
4-to-6 is a horrible mess. -- Henning Brauer, BS Web Services, http://bsws.de hb@bsws.de - henning@openbsd.org Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)