Subject: [dnsop] Removing ip6.int

From: David Conrad <[email-masked]>
Date: Thu, 6 Apr 2006 10:21:35 -0700

Hi,

Looking for a bit of advice...

On 1 June 2006, the RIRs are going to stop providing support for
ip6.int.

Is there any reason anyone can think of that says we shouldn't remove
ip6 from the int zone?

Thanks,

David Conrad
IANA
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 06 Apr 2006 22:18:08 +0200

> Is there any reason anyone can think of that says we shouldn't remove

Only one, which is the same as RFC1918: misconfigured (they are not
updated) implementations will try to query for it. Thus it might be an
idea to point ip6.int to the AS112 boxes.

On the other side, the query rate is so low that configuring it on AS112
is more of an overhead and annoyance than getting the queries in the
first place.

IMHO you can safely remove ip6.int from DNS.

Greets,
 Jeroen

---

From: [email-masked]
Date: Thu, 6 Apr 2006 21:27:15 +0000

> idea to point ip6.int to the AS112 boxes.

	since it is not a configuration option, i'm not sure
	this is an accuate statement... however the results
	are the same.  There is no good reason to dump yet more
	traffic onto the unsuspecting auth servers.

> IMHO you can safely remove ip6.int from DNS.

	and IMHO, no is not the time.  There is no harm in leaving the
	delegations in place.

.

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 06 Apr 2006 23:40:12 +0200

On Thu, 2006-04-06 at 21:27 +0000, [email-masked] wrote:
> 	this is an accuate statement...

On Solaris it is a configuration option. And the version of a resolver
certainly also falls under 'configuration' of the machine. Upgrade it.
That has been said to you and many other people already for the last
couple of years already.

>         however the results are the same.
>         There is no good reason to dump yet more

They get the lookup for ip6.int anyway, thus that does not matter and
the query rate is nice and low and almost non-existent. Especially when
3ffe::/16 disappears 6 days after the shutdown of ip6.int.

Recall that most of the 'old' resolvers, who are only able to do ip6.int
exist on the 6bone. Those people who still use it clearly don't care
about it and they can use their local ip6.int resolver to keep it
running.

But if you really want, just stick a:
ip6.int DNAME ip6.arpa.

in the roots and everybody will be happy (except Bill who looses his
domain)

> 	and IMHO, no is not the time.  There is no harm in leaving the

Bill, even *YOU* are not using it:

$ dig +trace ip6.int
[..]
;; Received 25 bytes from 2001:200:0:1800::1d4c:0#53(y.ip6.int) in 265
ms
$ ~/ip6_arpa.pl 2001:200:0:1800::1d4c:0
0.0.0.0.c.4.d.1.0.0.0.0.0.0.0.0.0.0.8.1.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa
$ dig +trace
0.0.0.0.c.4.d.1.0.0.0.0.0.0.0.0.0.0.8.1.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa
[..]
0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa. 3600 IN SOA	ns-wide.wide.ad.jp.
two.wide.ad.jp. 351 3600 900 3600000 3600
;; Received 148 bytes from 2001:200:0:1::8#53(ns.tokyo.wide.ad.jp) in
285 ms

$ host -t ptr
0.0.0.0.c.4.d.1.0.0.0.0.0.0.0.0.0.0.8.1.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa
0.0.0.0.c.4.d.1.0.0.0.0.0.0.0.0.0.0.8.1.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa
does not exist (Authoritative answer)

So come on get over it and shut it down. It was fun watching it being
broken for the last decade; see 6bone mailinglist and several other ops
lists which you read.

Greets,
 Jeroen

---

From: bert hubert <[email-masked]>
Date: Thu, 6 Apr 2006 23:33:31 +0200

> On 1 June 2006, the RIRs are going to stop providing support for

In a many-gigabyte dump of a recursor of a big internet provider here in The
Netherlands, the ratio between ip6.arpa to ip6.int queries is ten to one.

Measured in distinct IP addresses, the ratio is 4 to 1.

Both kinds of queries are extremely rare, so much that in abolute numbers, I
only have 50 packets to work with, but I checked around 50 million.

I know too little about ipv6 RIR delegations to have an opinion, but these
numbers might be useful.

 	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software
http://netherlabs.nl              Open and Closed source services
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: [email-masked]
Date: Thu, 6 Apr 2006 22:31:19 +0000

> I know too little about ipv6 RIR delegations to have an opinion, but these

	These numbers roughly match the data collected by Geo. Michaelson
	of APNIC.

--bill
.

---

From: [email-masked]
Date: Thu, 6 Apr 2006 22:28:28 +0000

> That has been said to you and many other people already for the last

	"upgrade" is not a configuration option... at least in
	the lexicon of most folks i know.  

> 3ffe::/16 disappears 6 days after the shutdown of ip6.int.

	for you, 3ffe::/16 has already disapeared, no?
	and you can't dictate what will happen to all sites
	globally can you?  Of course you can...  

> But if you really want, just stick a:

	been there, done that.   IANA didn't want to support it
	and given the DNS flexability for coding relative or absolute
	lables, one would have had to get everyone using this space to
	agree to NOT use FQDN's in their DNS configurations so that the
	DNAME haq will work.   I GUESS it could still be ram-rodded
	down the operations folks throats...

> in the roots and everybody will be happy (except Bill who looses his

	which domain is mine here?   If you refer to IP6.INT, it's not
	mine, i'm simply the custodian.  I don't care one way or the other
	if it stays or goes...  I do want stability for folks that still 
	want or need it and to minimize unneeded DNS traffic.
	Others seem to want to force change on otheres, where they are not 
	asked to pay to costs of migration.  
> Bill, even *YOU* are not using it:

	who ever said i was?

> <y.ip6.int>  ...  

	Ah.. the experimental testbed...  Sometimes it works, sometimes
	it does not...   at the moment, that particular machine is lame,
	since we moved the updates from the 3ffe:: space to 2001:: space
	and that site has not changed over, they are serving old data...

> broken for the last decade; see 6bone mailinglist and several other ops

	when/if the IANA asks me to... since the IANA asked me to set it
	up.  broken behaviour has a whole lot to do w/ lack of communication,
	-AND- some folks in the communities insistance that this delegation
	should be shunned along w/ 3ffe::... Orphans can't always be choosy.

	Now we can continue this cheerful debate...  but the important
	things have been said.  

	The IANA has asked the community if it would be ok to remove
	the delegation.
	You said YES.
	I said OK, with the caveat that shutting it down will cause some
	residual, unneeded traffic and there would be no harm it leaving the
	delegations intact.

	The rest is apparently a religious crusade to wipe out all remenants
	of the old ways.

.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Apr 2006 10:02:07 +1000

> 	down the operations folks throats...

	FUD

	On the wire all the names are absolute (even the compressed ones).
 
	The ONLY requirement is that all the authoritative servers for
	ip6.int support DNAME.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Apr 2006 12:04:19 +1000

http://v6fix.net/docs/ip6.int show that a number of current
	resolvers are still falling back to IP6.INT.  Until these
	resolvers are corrected to be arpa (nibble) only the load
	on the IP6.INT servers will only increase.

	Mark

---

From: [email-masked]
Date: Fri, 7 Apr 2006 02:08:32 +0000

> 	on the IP6.INT servers will only increase.

	presuming IANA leaves that delegation in place...
	if they pull it, the load goes to the INT servers...
	me, i'd need a COMPELLING reason to pull the delegations.
	i've not heard one yet... but its not my call. :)

--bill
.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Apr 2006 12:30:23 +1000

> 	i've not heard one yet... but its not my call. :)

	Ask Sun why they still fallback to IP6.INT.

	Ask the glibc developers why they still fallback to IP6.INT.

	I suspect the answers will be: "there is still information
	under IP6.INT that is not available under IP6.ARPA,
	in-particular local information and we can't break local
	reverse lookups for our customers."

	To be able to close down IP6.INT you have to get all the
	vendors to stop querying IP6.INT or remove the data available
	under IP6.INT globally.

	Deploying empty IP6.INT zones in recurive nameservers would
	allow local IP6.INT to still succeed without creating load
	on the global servers.  However I would only recommend this
	course if we can't convince Sun and glibc to fix there
	resolvers.

	Mark

---

From: [email-masked]
Date: Fri, 7 Apr 2006 03:00:11 +0000

> 	Ask the glibc developers why they still fallback to IP6.INT.

	nope... the IETF has been preaching the death of ip6.int for
	years and have declared it to historic, depricated, et.al.
	... kind of like what happened when the IETF declared RIPv1 dead.

	if developers have their own reasons for ignoring IETF edicts
	there is zero percentage in my asking them questions.  Or was this
	a retorical question?
 
> 	reverse lookups for our customers."

	Perhaps ... it took several heroic efforts to undo some (imho)
	misguided attempts to restrict any DNS entries in reverse maps to
	RIR's or their customers.  the 3ffe:: delegation took a serious hit
	with that "change"...  There is still some vestigal goo that only
	sits in ip6.int...  
> 	vendors to stop querying IP6.INT or remove the data available

	but whats the point?  instead of shooting the horse and trying
	to get unstuck from the mess left behind, a credible stratagy is
	to just leave the delegations in place to deal w/ the leftovers...
	eventually, after a suitable(*) mourning period, pull the delegations.
	whats the rush?  RIRs are not going to populate any data in this
	part of the tree...  this might be enough clue for OS/developers
	to figure out that the ip6.arpa arguement, while technically lame,
	is the wave of the future and they can be persuaded to change...

* imho 3 - 5 years.  i think it is finally time to shut off the pre-6bone
delegation...   the servers have gotten less than 10 queries this year... and
4 of them have been from me... :)

> 	course if we can't convince Sun and glibc to fix there

	There is some validity to keeping authoritative copies of 
	"special" zones ... but there is a real problem of when (not IF)
	there is a change required ... then there is the whole syncronization
	problem of having to upgrade (thousands, 10's of thousands, 100's
	of thousands?) of systems.   Experiences with the whole belt/suspenders
	thing over the last 15 years has been an effort in futility.

--bill

.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Apr 2006 14:37:27 +1000

> 	... kind of like what happened when the IETF declared RIPv1 dead.

	There is a big difference between declaring RIPv1 dead and
	declaring IPv6.INT dead.  Using RIPv1 between consenting
	parties doesn't impact on other people.  Continuing to
	perform ip6.int queries impacts on other people.  We wouldn't
	behaving this debate if there wasn't a impact.

	This is very much a case of "nip it in the bud".

> 4 of them have been from me... :)

	People stopped using those address.  They are not going to stop
	using IPv6 in general.

	How will you know when it is time to pull the delegations if you
	don't pull them now?  What metric do you intend to use?  Is that
	metric currently being met?

	At the moment all I've see reported is that there are queries.

	I'd like to see a break down like 

		NODATA IP6.INT and NODATA IP6.ARPA
		NODATA IP6.INT and DATA IP6.ARPA
		DATA IP6.INT and NODATA IP6.ARPA
		DATA IP6.INT and DATA IP6.ARPA

	where DATA is the there is a RRset there and NODATA is there
	was no records of the requested type or the was name error returned.
	servfail and refused should also be treated as no data.

	The interesting one is DATA IP6.INT and NODATA IP6.ARPA.  Is
	a suitable metric < 50%, < 25%, < 10%, < 5%, < 1%, < .05%?
	
	Can we get an anlysis of the last month's IP6.INT queries as
	seen by the IP6.INT servers and generate the above statistics?

	Mark

---

From: Peter Koch <[email-masked]>
Date: Fri, 07 Apr 2006 10:39:27 +0200

> 	seen by the IP6.INT servers and generate the above statistics?

Whatever that number is it will change for two reasons:

1) Every query that's answered by one of the RIR's servers will have to
   be NXDOMAINed by the ip6.int servers once the delegations have been
   revoked.

2) As soon as network administrators start to also remove their ip6.int
   zones, probably without making sure at the same time they don't
   generate any such queries, these queries will hit the 'live servers'
   instead of being answered locally (independent of any delegation).

That said, i still believe ip6.int should go away. No longer supporting
it is probably the best sign to indicate its end-of-life.
Re-delegating ip6.int to AS112 is a different issue.

-Peter
.

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Apr 2006 20:15:04 -0700

Hi,

On Apr 6, 2006, at 2:27 PM, [email-masked] wrote:
>>> Is there any reason anyone can think of that says we shouldn't  
>>> remove ip6 from the int zone?
> and IMHO, no[w] is not the time.  There is no harm in leaving the  
> delegations in place.

My question was whether there was any harm in removing the  
delegation.  Can anyone think of anything that might break should  
ip6.int be removed?

Thanks,
-drc

P.S. Telling people "historical reasons" for why ip6.int continues to  
exist in a domain that is (now) explicitly for "intergovernmental  
organizations" isn't a particularly satisfying response.

.

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Apr 2006 20:57:10 -0700

Hi,

Because several people have asked me to (publicly) clarify:

On Apr 6, 2006, at 3:28 PM, [email-masked] wrote:
>> in the roots and everybody will be happy (except Bill who looses  
>> his domain)
> mine, i'm simply the custodian.
...
> when/if the IANA asks me to... since the IANA asked me to set it up.

Jon (presumably, I wasn't there) asked Bill to set up ip6.int.  I am  
not aware of anyone currently at IANA being involved in having  
ip6.int set up or asking Bill to have any role in its operation.   
Bill is not an employee of ICANN, of which IANA is (now) a function.  
Current IANA staff did not ask Bill to be 'custodian' of ip6.int (I  
wasn't even aware he assumed that role), although his voluntarily  
acting in that role is appreciated.

Now, back to our regularly scheduled program...

Thanks,

David Conrad
IANA

.

---

From: [email-masked]
Date: Sat, 8 Apr 2006 05:10:32 +0000

> acting in that role is appreciated.

	that is correct.  one of those little handoff
	problems when Jon died and there was incomplete
	understanding by ICANN on just what the extent of
	stuff they had inherited.  Not that they have ever
	come asked or been interested when the information
	was offered. Me still working for a dead guy and
	without budget... :)

--bill
exIANA staff.

.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 11 Apr 2006 15:13:46 +0200

> Is there any reason anyone can think of that says we shouldn't remove

The trade off is being kind to those folk that still use it or force  
them to swallow a bitter pill.

Except for a possible bad aftertaste I do not think that the pill  
does harm.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/