&

& DNS and IPv6 IPv6 Summit, Canberra 31st October & 1 st November 2005 Chris Wright, Chief Technology Officer &

& Introduction

& Chicken & Egg Problem Service Providers - need content before migrating users – There has to be a benefit Content providers - need users before they will provide content – They are (generally) businesses Both parties require top-level infrastructure

& IPv6 enabling DNS – 1 st Step Users need DNS to access content in a “user-friendly” manner Content providers need DNS to direct users to their content System & Network Administrators need DNS to simplify configuration and management IPv6 enabling DNS is the first step towards a solution Need both the ability to access DNS via IPv6 and the ability for IPv6 records to be published in the DNS

& IPv6 & The Domain Name System

& IPv6 & DNS – Potential Issues Increased packet size (larger resource records) Accessibility Issues Standardised resource records Maintaining backward compatibility Increased Database size = increased hardware requirements

& Summary of Changes New Resource Records Provisioning Changes (Registry) DNS Extensions (not IPv6 exclusive)

& The ‘Quad A’ Record (AAAA) Similar to ‘A’ Resource Record for IPv4 (RFC3596) Holds the IPv6 Record for a host Entered into zone file in standard representation Backward compatible with (most) non-IPv6 aware resolvers (ignored RR type)

& The ‘Reverse Pointer’ Record (PTR) Not really a ‘new’ resource record (RFC3596) Zone cuts at the “nibble” boundary (as apposed to the byte boundary with IPv4) Backward compatible with (most) non-IPv6 aware resolvers (ignored)

& The Experimental Records (A6, DNAME) Enable split records (provider, client) (RFC2672 & RFC2874) Provide for provider renumbering, independent of client Require significant protocol changes (not backward compatible – binary fields in RR) Currently depreciated to “experimental” status by IETF to assess the need (as per RFC3363, RFC3364)

& Other Protocol Changes (Potential) EDNS0 (RFC2671) Larger UDP packets Addition of new label types – not backward compatible (necessarily)

& DNS software changes BIND 8 – AAAA Resource records, no native IPv6 transport (patch available) BIND 9 – All currently defined IPv6 record types, native IPv6 transport djbns – AAAA RR only, IPv6 transport only with patch NSD – as per BIND 9

& Migration Guidelines (IPv4 & IPv6 mixed environments) How to transition without affecting availability? All recursive name servers should be IPv4 only or dual stack hosts All zones should be served by at least one authoritative IPv4 capable host Defined in RFC3901

& Where are we at now?

& Name Services for the root and GTLD’s (.com,.net etc) Root – none IPv6 accessible.com/.net – 2 out of 13 IPv6 accessible.org/.info – 2 out of 5 IPv6 accessible * These taken from zone files, doesn’t take into account actual number of servers etc. (eg. any-casting)

& Glue Records for the gTLD’s (.com,.net etc) All major gTLD’s support publishing IPv6 glue records. None enforce any particular rules (as discussed previously)

& Name Services for.au and the 2LD’s (.com.au,.net.au etc) Currently no name services at the ccTLD and the 2LD’s are accessible via IPv6 transport Migration plans are in place Expected completion date – 1 st half of next year

& Glue Records for.au and the 2LD’s (.com.au,.net.au etc) Currently.au Registry system has full support for IPv6 glue records AAAA record format is used Will be implementing full checks and not allowing delegations that violate the recommendations of RFC3901

& Creating an IPv6 Test bed in Australia Need to establish IPv6 backbone so that providers can access DNS via their IPv6 addresses Encourage use of IPv6 within Australia Facilitate migration – guaranteed DNS services IPv6-IPv4 gateways

& Thank You Questions?

&

&