RFC 1886 Interoperability Testing

RFC 1886 defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address (IP6.INT), and updated definitions of existing query types that return Internet addresses as part of additional section processing.

Since 1995, RFC 1886 has been updated by RFC 3152. RFC 3152 deprecates the use of IP6.INT and replaces it by IP6.ARPA.
It is proposed to test IP6.INT and IP6.ARPA .

A first set of tests was hosted by AFNIC on June 3rd 2002 with the help of 6WIND and of the G6 (French association for the deployment of IPv6).
Attendee list :

     Vincent Levigneron   : AFNIC
     Mohsen Souissi         : AFNIC
     Luc Beloeil               : France Telecom R&D
     Sébastien Barbin       : IRISA
     Frédéric Roudaut      : IRISA
     Jean Mickaël Guerin : 6WIND
     Alain Ritoux              : 6WIND
     Vladimir Ksinant        : 6WIND

After this first session, it appeared that it was necessary to carry some more tests.

The second set of tests were hosted by 6WIND on July 4th 2002 with the help of AFNIC and of the G6.
Attendee list :

Vincent Levigneron   : AFNIC
Mohsen Souissi         : AFNIC
Jean Mickaël Guerin : 6WIND
Alain Ritoux              : 6WIND
Vladimir Ksinant        : 6WIND

Comprehensive list of RFC 1886 sections with explanation of specific test needs

Section 1 (Introduction)

This section does not require interoperability testing.

Section 2 (NEW RESOURCE RECORD DEFINITION AND DOMAIN)

This section of RFC 1886 defines the new record type (AAAA) that stores a single IPv6 address. It also defines its format, textual representation and the use of the IP6.INT domain. The support of AAAA records by the different implementations must be tested.
It is necessary to test the following records : A, AAAA, PTR for IP6.INT and PTR for IP6.ARPA.
A second set of tests is also needed in order to check servers interoperability when using AXFR.

Section 3 (MODIFICATIONS TO EXISTING QUERY TYPES)

This section of RFC1886 specifies that all existing query types that perform type A additional section processing, i.e. name server (NS), mail exchange (MX) and mailbox (MB) query types, must be redefined to perform both type A and type AAAA additional section processing. These new definitions mean that a name server must add any relevant IPv4 addresses and any relevant IPv6 addresses available locally to the additional section of a response when processing any one of the above queries. The support of IPv4 and IPv6 addresses must be tested for these query types.

The commonly used records types with "A" additional processing are :

CNAME records (not mentioned in RFC1886)
MX records (mentioned in RFC1886)
NS records (mentioned in RFC1886)
PTR records (mentioned in RFC1886, but not explicitly)
SRV records (not mentioned in RFC1886)
SOA records (not mentioned in RFC1886)

It is necessary to test the following records : CNAME, MX, NS, SRV, SOA.
A second set of tests is also needed in order to check servers interoperability when using AXFR.

Section 4 (Security Considerations)

This section does not require interoperability testing.

Notes

Note 1 : RFC 1886 does not specify which IP version should be used in order to transport queries and answers. Some implementations support only IPv4 Transport, so IPv4 transport was required in order to test RFC 1886 interoperability.
Note 2 : The size of the DNS messages has been kept low in order to avoid truncation problems.

Overview of test plan

Implementations

In order to test interoperability, several resolver and server implementations were used :

Dig 8.3 on FREEBSD and nslookup on Windows XP for the resolvers and test applications.
3 different implementations (X, Y and Z) for the servers.

Transport

DNS messages can be transported using IPv4 or IPv6. Some implementations currently support only IPv4 transport, so IPv4 was used during the tests.

Features to be tested

The tests were divided in two categories :

Records tests

A, AAAA records support
NS, CNAME, MX , SRV records support
SOA support
IP6.INT

inverse res. (PTR),

IP6.ARPA (RFC 3152)

inverse res. (PTR),

AXFR tests (master and slaves)

TESTS AND RESULTS

Records tests

Results show that :

Server implementations X and Y are fully interoperable as defined in RFC1886 (section 2 and section 3).
The two resolvers have identical behaviors.
Server Z is partially in conformity with RFC 1886:

It does not seem to support IP6.ARPA
When the record is in the local database, server Z does not perform correctly additional section processing (section 3 of RFC1886) for MX, SRV, NS and SOA .
When the record is not in the local database, Server Z does not restitute correctly the answers received from other servers (for MX, SRV, NS and SOA) .

Client <= slave <= master tests and Client <= slave <= slave <= master tests

Results show that server implementations X, Y and Z are fully interoperable in terms of RFC1886 AXFR.