Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)

From: Jeroen Massar <[email-masked]>
Date: Thu, 22 Jul 2004 11:46:17 +0200

On Thu, 2004-07-22 at 10:57, Anand Kumria wrote:
> On Thu, Jul 22, 2004 at 10:10:19AM +0200, Jeroen Massar wrote:
> > [ Cross-post, to get everybody in sync,
> > Other messages in this thread can be found at:
> > http://www.ripe.net/ripe/mail-archives/ipv6-wg/2004/msg00089.html ]
> > 
> > On Thu, 2004-07-22 at 09:58, Kurt Erik Lindqvist wrote:
> > 
> > > On 2004-07-22, at 09.43, Jeroen Massar wrote:
> > > 
> > > > But indeed, if there is concensus or not 9/9/2004 and ip6.int is gone
> > > > for me.
> > > 
> > > I vote for 9/9/2004 and getting rid of it properly. Maintaining two 
> > > reverse threes will create more problems than it will solve.
> 
> What, specifically, is the hurry? 

That this has been overdue for three years already and that even though
the deprecation was marked in August 2001 some vendors still not have
done the change. And as it is a s/ip6.int/ip6.arpa/g which is very easy,
if vendors did not do that yet they are way overdue and you got to
wonder how much their interest is in keeping software upto date.

Basically we (at least me) have been waiting for the 6bone to get the
delegation so that we could remove the 2 trees and only keep one:
ip6.arpa. This was decided by the IAB thus we should live up to it.

If we do not remove ip6.int then still implementations using it will
not show up. They have had 3 years already to update...
 
> > Take your pick:
> > 
> > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-removal-00.html
> > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-removal-00.txt
> > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-removal-00.xml
> > 
> > Short, quick and easy.
> > If no comments are risen for 16:00 today I'll submit this as an ID.
> 
> Comments:
> 	e.f.f.3.ip6.arpa was documented in RFC3681 published in February
> 	2004 and actioned in July 2004.

Added, but note that this was all long overdue and there where a number
of other solutions that would have worked already 2 years ago if there
had not been any of the political arguments holding back this technical
issue. Note also that 6bone will end per 6/6/6 and that it is a TESTbed.
The TESTbed is delaying and thus hurting the production networks in this
case.

> 	I'm assuming the actioning of e.f.f.3.ip6.arpa is the trigger
> 	for this I-D; if so, why do you want to wait so little time (2
> 	months) between e.f.f.3.ip6.arpa becoming available and
> 	requiring people to have updated resolver libraries?

People should have updated their resolvers in the last *3 years*.
If you have not done that already then you are not maintaining your
machines properly and there is a big chance that you have bigger
problems than a IPv6 reverse DNS that doesn't work anymore because
ip6.int is gone.

> 	Personally I'd be more in favour of a 6 month timeout - i.e
> 	around last December or so.

Of course the date is up to discussion, but IMHO: ASAP and at least
before the end of the year, the sooner the better.

Note that Cisco's IOS updates will be done before that date and Windows
XP2 will come out in August (they say) thus everybody using IPv6 has
time enough to upgrade. All "free unix flavors" already support it 

Also users agree: http://www.sixxs.net/forum/?msg=general-83948
Note the begin date of that thread, we where really waiting for 6bone
just as being nice to the people still using it.

On Thu, 2004-07-22 at 10:57, Rob Blokzijl wrote: 

> > If no comments are risen for 16:00 today I'll submit this as an ID.
> 
>     two minor points. In the abstract and the introduction you write:
>       
>       RFC 3152 delegates IP6.ARPA for reverse IPv6 delegations. For RIRs 
>       (RIPE,ARIN,APNIC,LACNIC and soon AFNIC)
> 
>     Replace RIPE --> RIPE NCC

That I did that wrong is a major oops, I should by know the difference by now.

>     Replace AFNIC --> AFRINIC
> 
>       (AFNIC is the .fr registry :-) )

Also adjusted and added some xref's in the XML.

Old version is now draft-massar-v6ops-ip6int-removal-00.a new version
carries the draft-massar-v6ops-ip6int-removal-00 name.

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 22 Jul 2004 13:27:42 +0200

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

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 22 Jul 2004 14:13:36 +0200

On Thu, 2004-07-22 at 12:11, Andrei Robachevsky wrote:
> Jeroen, all,
<SNIP>

> We were discussing possible ways of ip6.int phaseout with other RIRs, 
> and one approach was presented at the last RIPE meeting in May 
> (http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-reverse-ipv6.pdf). 
> It is a bit less radical than yours.

I noticed the presentation, but couldn't find the minutes as I wasn't
there myself. And due to technical reasons on my behalf I couldn't check
the webcast nor from the archive.

> Description of the plan is attached.

Timing it out slowly seems a good idea but in an off-list discussion
with some people the following example by Daniel Roesen, why a direct
cut-off would be the best to do:

8<-----------------
CustA gets 2001:db8:1000::/48
CustA installs reverse for 2001:db8:1000::/48 in the ip6.int tree
CustA changes ISP and gets another /48

CustB gets 2001:db8:1000::/48
CustB installs reverse for 2001:db8:1000::/48 in the ip6.arpa tree

Thus the ip6.int tree still points to the NS's from CustA.
As CustA didn't remove those entries from their nameserver now the
following happens:

CustC didn't upgrade their resolvers
CustC thus notices in it's logs that the reverses for
      2001:db8:1000::/48 are from CustA

CustD did upgrade their resolvers
CustD thus notices in it's logs that the reverses for
      2001:db8:1000::/48 are from CustB
----------------->8

Thus depending if you upgraded or not you will be getting different
results, which could have effects on the

It is thus better to have *NO* IP6.INT zone as then the reverses will
revert back to IPv6 numbers which is consistent with the IP6.ARPA tree.

Should this example be included in the draft or do we want to keep it
short?

Greets,
 Jeroen

---

From: [email-masked]
Date: Sun, 25 Jul 2004 21:45:01 +0000

whjile i applaud each and everyone who has expunged
	all ip6.int from their lives, the fact of the matter is that
	IETF fiat or no, there exist -many- systems that can only use
	reverse maps in the ip6.int tree.   

	it will be maintained as long as there are queries for 
	it.  for those of you for whom ip6.int is a distant memory,
	pleae understand and respect the fact that you can not, 
	despite public posturing, force others to change their 
	systems. to practically remove ip6.int incures real cost
	in both time and cash.  in the US there is a term for what
	the IETF is trying to do w/ ip6.int.  Its called an unfunded
	mandate.  Unless or until the good folk in the IETF who are
	calling for the removal of ip6.int are ready to put up the 
	cash to effect real change, I wish they would stop.

> *              sig-ipv6:  APNIC SIG on IPv6 technology and policy issues           *
> _______________________________________________
> sig-ipv6 mailing list
> [email-masked]
> http://mailman.apnic.net/mailman/listinfo/sig-ipv6

---

From: Pekka Savola <[email-masked]>
Date: Mon, 26 Jul 2004 10:33:50 +0300 (EEST)

(FWIW, I think this is a bit off-topic for v6ops..)

> 	cash to effect real change, I wish they would stop.

Let's put this in another way..

Are you paying for us (or a number of other bodies) for continuing to
support ip6.int?  Was its use granted to you in perpetuity?  (I guess
you're paying at least for ARIN or similar body, but whether one can
read this in the contract is another topic.)

Unless or until the folks who want to have a free lunch are ready to 
put up the cash to continue maintaining old service just for them, I 
wish they would stop.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Paul Vixie <[email-masked]>
Date: 26 Jul 2004 17:32:40 +0000

Considering the DNAME-baed renaming mechanism documented at
<http://www.isc.org/pubs/tn/isc-tn-2002-1.txt>, what I wonder
is, why doesn't Bill Manning just put in a DNAME at IP6.INT
renaming the whole tree to point at IP6.ARPA?

Older client implementations will be out there forever.  The
right transition mechanism might be "all at once, and forever."
-- 
Paul Vixie