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:
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
-
IP6.ARPA (RFC 3152)
-
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
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.
Results show that server implementations X, Y and Z are fully interoperable
in terms of RFC 1886 AXFR.