Inside ICANNWatch  
Submit Story
Lost Password
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)

    This discussion has been archived. No new comments can be posted.
    Twomey ponders, Pisanty Fumes at TLD process deadline | Log in/Create an Account | Top | 15 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    ICANN (IANA) Secretly Moves IPv6 Out of ITU Hands
    by Anonymous on Monday July 26 2004, @08:11AM (#14041)
    While no one is paying attention, in true ICANN
    (IANA) fashion, the **control** of IPV6, via the
    address space DNS reverse delegation servers,
    is being moved AWAY from the ITU to the good
    old DOD-backed .ARPA.

    Jon Postel's crony, Bill Manning (ARIN and USC/ISI and EP.NET)
    is of course at the middle of the activity.
    Jim Bound (HP) of course runs around telling
    everyone that his top-secret DOD contacts are
    adopting IPv6, for those that want to sell
    gear to the U.S. Government. It is amazing that
    now Quality Assurance (QA) is being used in the
    same breath as IPv6. IPv6 is being **declared**
    production-ready because the insiders say it is.

    http://www.ripe.net/ripe/mail-archives/ipv6-wg/200 4/msg00127.html

    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

    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,

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


    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 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@localhost 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.
    > Can you identify those vendors which didn't react to a RFC
    > from 3 years ago?

    No that is up to those vendors product managers etc. What I know is
    from interoperability testing and cannot reveal. You missed mine and
    Bill's entire point. No one is against doing this it is a matter
    getting it into the production DNS code base. I think Bill should answer
    your other questions as you integrated my mail with Bill's. Your
    complaining here in IETF at least is irrelevant. And not the purpose of
    the IETF list IMO. I will not respond to other mail. If you want to
    discuss offline send me mail and I suggest you copy Bill. Ipv6.arpa is
    supported in the latest BIND releases and IMO all should be doing it,
    but I don't attribute it to being lazy at all. Again IPv6 is production
    code now vendors can't just change it as we do the public domain and
    university code base, it requires QA et al per the customer and that has
    cost and all changes to IPv6 at this point. /jim
    [ Reply to This | Parent ]

    Search ICANNWatch.org:

    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com