[ipv6-wg at ripe.net] RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)

On Mon, 2004-07-26 at 12:54, Bound, Jim wrote:
> Well stated Mr. Manning.  Same for any updates from IETF for IPv6 (e.g.
> 2461, 2462, SEND, Optimistic DAD) as every vendor I know (e.g. routers,
> switches, servers, clients, embedded systems) is shipping production
> IPv6 within their OS release.

Can you identify those vendors which didn't react to a RFC from 3 years
ago?

I know that Windows XP doesn't do it yet, but will with SP2.
And a fair amount of Cisco IOS's.

Neither of these are servers thus don't require reverses to resolve.
Routers don't need resolving, Switches? ehm Layer2, those don't do IPv6
and certainly don't need resolving ;)
Any others that haven't been converted in the last three years?

> Any changes now to IPv6 will undergoigorous Q&A,

<SNIP fairytale about slow people suddenly being awakened>

You really need to check ip6.arpa? I'd rather be quite anxious in using
the following set of servers:

ip6.int.                86400   IN      NS      flag.ep.net.
ip6.int.                86400   IN      NS      y.ip6.int.
ip6.int.                86400   IN      NS      z.ip6.int.
ip6.int.                86400   IN      NS      ns3.nic.fr.
;; Received 266 bytes from 128.9.128.127#53(ns.isi.edu) in 165 ms


I only believe ns3.nic.fr to be a production server which is actually
pro actively maintained as can be seen from the various reports send to
the 6bone mailinglist about the non-workings of ip6.int.
For that matter they are broken currently too:

http://www.zonecut.net/dns/

Mon Jul 26 12:51:05 UTC 2004
y.ip6.int A record currently not present
ip6.int             	NS	ns3.nic.fr
z.ip6.int	hostmaster.ep.net	(1925907 10800 900 604800 129600)
ip6.int             	NS	flag.ep.net
Nameserver flag.ep.net not responding
ip6.int SOA record not found at flag.ep.net, try again
ip6.int             	NS	z.ip6.int
z.ip6.int	hostmaster.ep.net	(1925907 10800 900 604800 129600)

and totally out of sync, just check the picture that that url produces.
This is just like last year and the year before, but people gave up complaining
about it as there is apparently only one person who runs ip6.int.

> The IPv6 Forum and NAv6TF can help here where the IETF cannot, and I
> will take this to the members and industry, but it will take time.  It
> is a deployment issue not a standards issue at this point.

The deployment issue is more a lazy administrator issue and also a
political issue. The lazy administrators who do not want to upgrade and
the political issue where some people want to keep some ropes tied to
themselves so they can keep on pulling some strings.

> P.S. Bill - the new initial IPv6 AAA at root for JP and KR are they to
> use ipv6.arpa?  Thanks.

And FR also with a couple of others following. I don't see any US based
name servers there though, odd. Then again this is for _forward_
resolving, the reverses served through ip6.arpa are delegated to:

ip6.arpa.               172800  IN      NS      ns.apnic.net.
ip6.arpa.               172800  IN      NS      ns.icann.org.
ip6.arpa.               172800  IN      NS      ns.ripe.net.
ip6.arpa.               172800  IN      NS      tinnie.arin.net.
;; Received 126 bytes from 193.0.14.129#53(K.ROOT-SERVERS.NET) in 6 ms

(K is started to do IPv6 too, at least the peerings are coming up ;)

Fortunatly the above 4 servers are production and there are people
paying attention to them, unlike the aforementioned ip6.int machines in
somebodies private domain.


On Sun, 2004-07-25 at 23:45, bmanning at vacation.karoshi.com wrote: 
> 	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.   

As I just asked Jim, which "systems" are those?
I also wonder if those are not updated how big virustraps they are ;)

> 	it will be maintained as long as there are queries for 
> 	it.

Then we can shut it down quite quickly now can't we?
And why let a lot of people pay hard cash for maintaining something
which is near gone only because a few are too lazy to update?

>         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.

Then please donate the rest of the world, thus except for the few
of you who don't update, real cash for continuing to maintain ip6.int
which has a lot of broken delegations for alone ip6.int, not even
checking the rest, see above.

I also wonder why the "US" is brought up while the "US" hasn't been so
active in the whole IPv6 soup until late.

ip6.int will be gone for me and thus 30%+ of the current IPv6 endsite
delegations (check the RIPE database :), 31st of December 2004 is the
last date this is going to wait. But I'd rather see it pulled down
nicely in cooperation than doing it that way. Nevertheless that 30%
userbase has already voted in favor and don't see the problem at all.
Then again they actually update their systems as they want to be able
to use the newest features: IPv6 for instance.

I also repeat again: there is nothing *BAD* about having a reverse-
resolve which doesn't work. One simply gets an IPv6 address in their
logs, too bad, you should have upgraded 3 years ago then.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
URL: </ripe/mail/archives/ipv6-wg/attachments/20040726/17d8ed99/attachment.sig>