On Thu, 2004-07-22 at 12:30, Iljitsch van Beijnum wrote: > On 22-jul-04, at 12:18, Jeroen Massar wrote: > > >> I don't see any benefits to removing the ip6.int delegation in the > >> first place. It makes much more sense to do this from the leaves up > >> than from the root down. > > > The leaves already have started falling in many places. Doing this > > quickly will make sure that everybody knows it can be removed from > > their > > systems and will identify the implementations that have not been > > upgraded yet. > > I still don't see any reason to remove the delegation, and especially > any reason to do it sooner rather than later. It's there, it isn't in > the way, just leave it. We have better things to do than babysit IRC > users who can't connect because their reverse mapping doesn't work > anymore. To flush out all the faulty implementations that could have been updated already in the last three years. IRC users don't care about this. All the IRCd's of at least the bigger networks have already been upgraded at least 2 years ago. FYI irc.song.fi only uses ip6.arpa while several others first try ip6.arpa and then fallback to ip6.int. The reason they had to have a fallback mechanism is because of the ip6.int still being used by 6bone and there was, for those users, no alternative, there is now thus let's get rid of it. > >> However, if this is going to happen, doing it this year is way too > >> soon, as current IOS and Windows XP (both in wide use) rely on > >> ip6.int. > > > IOS updates are there > > In all trains that support IPv6 or just some? Some, but then again not every train supports IPv6 that well either ;) Apparently it is very hard to do s/ip6.int/ip6.arpa/g for even a company like Cisco... Then again, how hard does your 'production router' depend on the existence of ip6.int. It is no server and your logs will now show the IPv6 addresses. Is this a problem? IMHO absolutely not. Complain to your vendor that they are late. > > if you are using IPv6 you want to use new software (Debian > > unstable/testing ;) anyways. Thus upgrading is not an issue. > > Wait until you get a real job with real users that get you fired for > real when you screw up their service. I have customers who run IPv6 > images on their production routers, upgrading IS a big deal there. See http://www.sixxs.net/forum/?msg=general-83948 these 'real customers' like the idea very well, they might not be paying for the service but they do like that it works and believe me they do complain when it does not even though they get it for free. Fortunately the problems are minimal and don't happen that much and we already announced to pull the plug on ip6.int some time ago when this event (e.f.f.3.arpa going live) would occur. Also there is something called 'maintenance' that goes very well when upgrading machines, of course after you tested them in your non-production testbed. > > FTP/Mailservers/etc are servers and should run on Windows 2003 Server > > and not on XP "Pro" or even "Home". > > So now the IETF is in the business of telling people what OS they can > use for what purpose?? That is what Microsoft demands from them, read their EULA's. XP's IIS for instance is capped at 10 concurrent threads etc. There is a reason why they call it 'home' and 'server', just like you have MAC OS X Server and Redhat Enterprise. You get what you pay for. > > Waiting on vendors because they don't update their implementation is > > useless especially for this. They had their chance for 3 years already > > and they claim to be IPv6 compliant. > > Waiting for 3 years and THEN do it moments before they're ready is > useless. Either it should have been done immediately as there was no > production stuff running IPv6 back then (AFAIK), or just take it > slowly, there is no rush. Now is not the time. All the production 'stuff' is running in RIR space and RIR space has had ip6.arpa since the beginning of ip6.arpa. Thus that is a non issue. Greets, Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part