RFC 1886 Implementation Report

RFC 1886 Interoperability Testing (last updated on March 20th 2003)

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

IP6.INT
IP6.ARPA

A first set of tests was hosted by AFNIC on June 3rd 2002 with the help of 6WIND and 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 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 tests.

Section 2 (NEW RESOURCE RECORD DEFINITION AND DOMAIN)

This section of RFC1886 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.
CNAME records also needs to be tested as the CNAME may point to an AAAA name or to an A name.

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 RFC 1886 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 anyone of the above queries. The support of IPv4 and IPv6 addresses must be tested for these query types.

A description of existing query types is provided in DNS records types. The records are classified in commonly used records and less commonly used or experimental records.

The commonly used records types which use type A additional processing are:

MX records (mentioned in RFC 1886)
NS records (mentioned in RFC 1886)
SRV records (not mentioned in RFC 1886 as they were defined later)

As stated in RFC 1035, Start Of Authority (SOA) records cause no additional section processing. However, many implementations place NS RRset in the authority section, which causes additional section processing. So, additional section processing of the authority section was also tested to see what implementors have done there.

It is necessary to test the MX NS and SRV records, SOA was also tested.

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

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 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 servers implementations were used.

Dig 8.3 on FREEBSD and nslookup on Windows XP were used for the resolvers and test applications.

Concerning the servers, 3 different implementations were used (X, Y and Z).

Transport

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

Features to be tested

The tests were divided in two categories. The results of these tests should be successful.

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)

A, AAAA records support
NS, CNAME, MX , SRV records support
SOA support
inverse res. (PTR) for IP6.INT,
inverse res. (PTR) for IP6.ARPA,

TESTS

Records tests

Results show that :

Server implementations X and Y are fully interoperable in terms of RFC 1886 (section 2 and section 3).
The two resolvers have identical behaviors.
At the time of the interop tests, server Z does not support IP6.ARPA (RFC 3152).
Server Z has the following limitations in terms of RFC 1886 support:
- When the record is in the local data-base, Server Z does not perform correctly additional section processing (section 3 of RFC1886) for MX, SRV and NS. In the same manner, server Z does not perform correctly additional section processing of authority section in SOA.
- When the record is not in the local data-base, Server Z does not restitute correctly the answers received from other servers (for MX, SRV, NS and SOA) .
We reported the issues above to the implementors. The identification of the causes of these issues is out of scope of this IETF interop report.

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 RFC 1886 AXFR.