1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
|
Network Working Group M. Crawford
Request for Comments: 2874 Fermilab
Category: Standards Track C. Huitema
Microsoft Corporation
July 2000
DNS Extensions to Support IPv6 Address Aggregation and Renumbering
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document defines changes to the Domain Name System to support
renumberable and aggregatable IPv6 addressing. The changes include a
new resource record type to store an IPv6 address in a manner which
expedites network renumbering and updated definitions of existing
query types that return Internet addresses as part of additional
section processing.
For lookups keyed on IPv6 addresses (often called reverse lookups),
this document defines a new zone structure which allows a zone to be
used without modification for parallel copies of an address space (as
for a multihomed provider or site) and across network renumbering
events.
Crawford, et al. Standards Track [Page 1]
RFC 2874 IPv6 DNS July 2000
Table of Contents
1. Introduction ............................................... 2
2. Overview ................................................... 3
2.1. Name-to-Address Lookup ............................... 4
2.2. Underlying Mechanisms for Reverse Lookups ............ 4
2.2.1. Delegation on Arbitrary Boundaries ............. 4
2.2.2. Reusable Zones ................................. 5
3. Specifications ............................................. 5
3.1. The A6 Record Type ................................... 5
3.1.1. Format ......................................... 6
3.1.2. Processing ..................................... 6
3.1.3. Textual Representation ......................... 7
3.1.4. Name Resolution Procedure ...................... 7
3.2. Zone Structure for Reverse Lookups ................... 7
4. Modifications to Existing Query Types ...................... 8
5. Usage Illustrations ........................................ 8
5.1. A6 Record Chains ..................................... 9
5.1.1. Authoritative Data ............................. 9
5.1.2. Glue ........................................... 10
5.1.3. Variations ..................................... 12
5.2. Reverse Mapping Zones ................................ 13
5.2.1. The TLA level .................................. 13
5.2.2. The ISP level .................................. 13
5.2.3. The Site Level ................................. 13
5.3. Lookups .............................................. 14
5.4. Operational Note ..................................... 15
6. Transition from RFC 1886 and Deployment Notes .............. 15
6.1. Transition from AAAA and Coexistence with A Records .. 16
6.2. Transition from Nibble Labels to Binary Labels ....... 17
7. Security Considerations .................................... 17
8. IANA Considerations ........................................ 17
9. Acknowledgments ............................................ 18
10. References ................................................ 18
11. Authors' Addresses ........................................ 19
12. Full Copyright Statement .................................. 20
1. Introduction
Maintenance of address information in the DNS is one of several
obstacles which have prevented site and provider renumbering from
being feasible in IP version 4. Arguments about the importance of
network renumbering for the preservation of a stable routing system
and for other purposes may be read in [RENUM1, RENUM2, RENUM3]. To
support the storage of IPv6 addresses without impeding renumbering we
define the following extensions.
Crawford, et al. Standards Track [Page 2]
RFC 2874 IPv6 DNS July 2000
o A new resource record type, "A6", is defined to map a domain name
to an IPv6 address, with a provision for indirection for leading
"prefix" bits.
o Existing queries that perform additional section processing to
locate IPv4 addresses are redefined to do that processing for both
IPv4 and IPv6 addresses.
o A new domain, IP6.ARPA, is defined to support lookups based on
IPv6 address.
o A new prefix-delegation method is defined, relying on new DNS
features [BITLBL, DNAME].
The changes are designed to be compatible with existing application
programming interfaces. The existing support for IPv4 addresses is
retained. Transition issues related to the coexistence of both IPv4
and IPv6 addresses in DNS are discussed in [TRANS].
This memo proposes a replacement for the specification in RFC 1886
[AAAA] and a departure from current implementation practices. The
changes are designed to facilitate network renumbering and
multihoming. Domains employing the A6 record for IPv6 addresses can
insert automatically-generated AAAA records in zone files to ease
transition. It is expected that after a reasonable period, RFC 1886
will become Historic.
The next three major sections of this document are an overview of the
facilities defined or employed by this specification, the
specification itself, and examples of use.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD]. The key word
"SUGGESTED" signifies a strength between MAY and SHOULD: it is
believed that compliance with the suggestion has tangible benefits in
most instances.
2. Overview
This section provides an overview of the DNS facilities for storage
of IPv6 addresses and for lookups based on IPv6 address, including
those defined here and elsewhere.
Crawford, et al. Standards Track [Page 3]
RFC 2874 IPv6 DNS July 2000
2.1. Name-to-Address Lookup
IPv6 addresses are stored in one or more A6 resource records. A
single A6 record may include a complete IPv6 address, or a contiguous
portion of an address and information leading to one or more
prefixes. Prefix information comprises a prefix length and a DNS
name which is in turn the owner of one or more A6 records defining
the prefix or prefixes which are needed to form one or more complete
IPv6 addresses. When the prefix length is zero, no DNS name is
present and all the leading bits of the address are significant.
There may be multiple levels of indirection and the existence of
multiple A6 records at any level multiplies the number of IPv6
addresses which are formed.
An application looking up an IPv6 address will generally cause the
DNS resolver to access several A6 records, and multiple IPv6
addresses may be returned even if the queried name was the owner of
only one A6 record. The authenticity of the returned address(es)
cannot be directly verified by DNS Security [DNSSEC]. The A6 records
which contributed to the address(es) may of course be verified if
signed.
Implementers are reminded of the necessity to limit the amount of
work a resolver will perform in response to a client request. This
principle MUST be extended to also limit the generation of DNS
requests in response to one name-to-address (or address-to-name)
lookup request.
2.2. Underlying Mechanisms for Reverse Lookups
This section describes the new DNS features which this document
exploits. This section is an overview, not a specification of those
features. The reader is directed to the referenced documents for
more details on each.
2.2.1. Delegation on Arbitrary Boundaries
This new scheme for reverse lookups relies on a new type of DNS label
called the "bit-string label" [BITLBL]. This label compactly
represents an arbitrary string of bits which is treated as a
hierarchical sequence of one-bit domain labels. Resource records can
thereby be stored at arbitrary bit-boundaries.
Examples in section 5 will employ the following textual
representation for bit-string labels, which is a subset of the syntax
defined in [BITLBL]. A base indicator "x" for hexadecimal and a
sequence of hexadecimal digits is enclosed between "\[" and "]". The
bits denoted by the digits represent a sequence of one-bit domain
Crawford, et al. Standards Track [Page 4]
RFC 2874 IPv6 DNS July 2000
labels ordered from most to least significant. (This is the opposite
of the order they would appear if listed one bit at a time, but it
appears to be a convenient notation.) The digit string may be
followed by a slash ("/") and a decimal count. If omitted, the
implicit count is equal to four times the number of hexadecimal
digits.
Consecutive bit-string labels are equivalent (up to the limit imposed
by the size of the bit count field) to a single bit-string label
containing all the bits of the consecutive labels in the proper
order. As an example, either of the following domain names could be
used in a QCLASS=IN, QTYPE=PTR query to find the name of the node
with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
\[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
2.2.2. Reusable Zones
DNS address space delegation is implemented not by zone cuts and NS
records, but by a new analogue to the CNAME record, called the DNAME
resource record [DNAME]. The DNAME record provides alternate naming
to an entire subtree of the domain name space, rather than to a
single node. It causes some suffix of a queried name to be
substituted with a name from the DNAME record's RDATA.
For example, a resolver or server providing recursion, while looking
up a QNAME a.b.c.d.e.f may encounter a DNAME record
d.e.f. DNAME w.xy.
which will cause it to look for a.b.c.w.xy.
3. Specifications
3.1. The A6 Record Type
The A6 record type is specific to the IN (Internet) class and has
type number 38 (decimal).
Crawford, et al. Standards Track [Page 5]
RFC 2874 IPv6 DNS July 2000
3.1.1. Format
The RDATA portion of the A6 record contains two or three fields.
+-----------+------------------+-------------------+
|Prefix len.| Address suffix | Prefix name |
| (1 octet) | (0..16 octets) | (0..255 octets) |
+-----------+------------------+-------------------+
o A prefix length, encoded as an eight-bit unsigned integer with
value between 0 and 128 inclusive.
o An IPv6 address suffix, encoded in network order (high-order octet
first). There MUST be exactly enough octets in this field to
contain a number of bits equal to 128 minus prefix length, with 0
to 7 leading pad bits to make this field an integral number of
octets. Pad bits, if present, MUST be set to zero when loading a
zone file and ignored (other than for SIG [DNSSEC] verification)
on reception.
o The name of the prefix, encoded as a domain name. By the rules of
[DNSIS], this name MUST NOT be compressed.
The domain name component SHALL NOT be present if the prefix length
is zero. The address suffix component SHALL NOT be present if the
prefix length is 128.
It is SUGGESTED that an A6 record intended for use as a prefix for
other A6 records have all the insignificant trailing bits in its
address suffix field set to zero.
3.1.2. Processing
A query with QTYPE=A6 causes type A6 and type NS additional section
processing for the prefix names, if any, in the RDATA field of the A6
records in the answer section. This processing SHOULD be recursively
applied to the prefix names of A6 records included as additional
data. When space in the reply packet is a limit, inclusion of
additional A6 records takes priority over NS records.
It is an error for an A6 record with prefix length L1 > 0 to refer to
a domain name which owns an A6 record with a prefix length L2 > L1.
If such a situation is encountered by a resolver, the A6 record with
the offending (larger) prefix length MUST be ignored. Robustness
precludes signaling an error if addresses can still be formed from
valid A6 records, but it is SUGGESTED that zone maintainers from time
to time check all the A6 records their zones reference.
Crawford, et al. Standards Track [Page 6]
RFC 2874 IPv6 DNS July 2000
3.1.3. Textual Representation
The textual representation of the RDATA portion of the A6 resource
record in a zone file comprises two or three fields separated by
whitespace.
o A prefix length, represented as a decimal number between 0 and 128
inclusive,
o the textual representation of an IPv6 address as defined in
[AARCH] (although some leading and/or trailing bits may not be
significant),
o a domain name, if the prefix length is not zero.
The domain name MUST be absent if the prefix length is zero. The
IPv6 address MAY be be absent if the prefix length is 128. A number
of leading address bits equal to the prefix length SHOULD be zero,
either implicitly (through the :: notation) or explicitly, as
specified in section 3.1.1.
3.1.4. Name Resolution Procedure
To obtain the IPv6 address or addresses which belong to a given name,
a DNS client MUST obtain one or more complete chains of A6 records,
each chain beginning with a record owned by the given name and
including a record owned by the prefix name in that record, and so on
recursively, ending with an A6 record with a prefix length of zero.
One IPv6 address is formed from one such chain by taking the value of
each bit position from the earliest A6 record in the chain which
validly covers that position, as indicated by the prefix length. The
set of all IPv6 addresses for the given name comprises the addresses
formed from all complete chains of A6 records beginning at that name,
discarding records which have invalid prefix lengths as defined in
section 3.1.2.
If some A6 queries fail and others succeed, a client might obtain a
non-empty but incomplete set of IPv6 addresses for a host. In many
situations this may be acceptable. The completeness of a set of A6
records may always be determined by inspection.
3.2. Zone Structure for Reverse Lookups
Very little of the new scheme's data actually appears under IP6.ARPA;
only the first level of delegation needs to be under that domain.
More levels of delegation could be placed under IP6.ARPA if some
top-level delegations were done via NS records instead of DNAME
records, but this would incur some cost in renumbering ease at the
Crawford, et al. Standards Track [Page 7]
RFC 2874 IPv6 DNS July 2000
level of TLAs [AGGR]. Therefore, it is declared here that all
address space delegations SHOULD be done by the DNAME mechanism
rather than NS.
In addition, since uniformity in deployment will simplify maintenance
of address delegations, it is SUGGESTED that address and prefix
information be stored immediately below a DNS label "IP6". Stated
another way, conformance with this suggestion would mean that "IP6"
is the first label in the RDATA field of DNAME records which support
IPv6 reverse lookups.
When any "reserved" or "must be zero" bits are adjacent to a
delegation boundary, the higher-level entity MUST retain those bits
in its own control and delegate only the bits over which the lower-
level entity has authority.
To find the name of a node given its IPv6 address, a DNS client MUST
perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the
128 bit address as one or more bit-string labels [BITLBL], followed
by the two standard labels "IP6.ARPA". If recursive service was not
obtained from a server and the desired PTR record was not returned,
the resolver MUST handle returned DNAME records as specified in
[DNAME], and NS records as specified in [DNSCF], and iterate.
4. Modifications to Existing Query Types
All existing query types that perform type A additional section
processing, i.e. the name server (NS), mail exchange (MX), and
mailbox (MB) query types, and the experimental AFS data base (AFSDB)
and route through (RT) types, must be redefined to perform type A, A6
and AAAA additional section processing, with type A having the
highest priority for inclusion and type AAAA the lowest. This
redefinition means that a name server may add any relevant IPv4 and
IPv6 address information available locally to the additional section
of a response when processing any one of the above queries. The
recursive inclusion of A6 records referenced by A6 records already
included in the additional section is OPTIONAL.
5. Usage Illustrations
This section provides examples of use of the mechanisms defined in
the previous section. All addresses and domains mentioned here are
intended to be fictitious and for illustrative purposes only.
Example delegations will be on 4-bit boundaries solely for
readability; this specification is indifferent to bit alignment.
Use of the IPv6 aggregatable address format [AGGR] is assumed in the
examples.
Crawford, et al. Standards Track [Page 8]
RFC 2874 IPv6 DNS July 2000
5.1. A6 Record Chains
Let's take the example of a site X that is multi-homed to two
"intermediate" providers A and B. The provider A is itself multi-
homed to two "transit" providers, C and D. The provider B gets its
transit service from a single provider, E. For simplicity suppose
that C, D and E all belong to the same top-level aggregate (TLA) with
identifier (including format prefix) '2345', and the TLA authority at
ALPHA-TLA.ORG assigns to C, D and E respectively the next level
aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and
2345:000E::/32.
C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
B.
A assigns to X the subscriber identification '11' and B assigns the
subscriber identification '22'. As a result, the site X inherits
three address prefixes:
o 2345:00C1:CA11::/48 from A, for routes through C.
o 2345:00D2:DA11::/48 from A, for routes through D.
o 2345:000E:EB22::/48 from B, for routes through E.
Let us suppose that N is a node in the site X, that it is assigned to
subnet number 1 in this site, and that it uses the interface
identifier '1234:5678:9ABC:DEF0'. In our configuration, this node
will have three addresses:
o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
5.1.1. Authoritative Data
We will assume that the site X is represented in the DNS by the
domain name X.EXAMPLE, while A, B, C, D and E are represented by
A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we
assume a subdomain "IP6" that will hold the corresponding prefixes.
The node N is identified by the domain name N.X.EXAMPLE. The
following records would then appear in X's DNS.
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
Crawford, et al. Standards Track [Page 9]
RFC 2874 IPv6 DNS July 2000
And elsewhere there would appear
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
5.1.2. Glue
When, as is common, some or all DNS servers for X.EXAMPLE are within
the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
enough "glue" information to enable DNS clients to reach those
nameservers. This is true in IPv6 just as in IPv4. However, the A6
record affords the DNS administrator some choices. The glue could be
any of
o a minimal set of A6 records duplicated from the X.EXAMPLE zone,
o a (possibly smaller) set of records which collapse the structure
of that minimal set,
o or a set of A6 records with prefix length zero, giving the entire
global addresses of the servers.
The trade-off is ease of maintenance against robustness. The best
and worst of both may be had together by implementing either the
first or second option together with the third. To illustrate the
glue options, suppose that X.EXAMPLE is served by two nameservers
NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
Then the top-level zone EXAMPLE would include one (or more) of the
following sets of A6 records as glue.
Crawford, et al. Standards Track [Page 10]
RFC 2874 IPv6 DNS July 2000
$ORIGIN EXAMPLE. ; first option
X NS NS1.X
NS NS2.X
NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X
SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X
IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
$ORIGIN EXAMPLE. ; second option
X NS NS1.X
NS NS2.X
NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
$ORIGIN EXAMPLE. ; third option
X NS NS1.X
NS NS2.X
NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111
A6 0 2345:00D2:DA11:1:1:11:111:1111
A6 0 2345:000E:EB22:1:1:11:111:1111
NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222
A6 0 2345:00D2:DA11:2:2:22:222:2222
A6 0 2345:000E:EB22:2:2:22:222:2222
The first and second glue options are robust against renumbering of
X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
those providers' own DNS is unreachable. The glue records of the
third option are robust against DNS failures elsewhere than the zones
EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
address space is renumbered.
If the EXAMPLE zone includes redundant glue, for instance the union
of the A6 records of the first and third options, then under normal
circumstances duplicate IPv6 addresses will be derived by DNS
clients. But if provider DNS fails, addresses will still be obtained
from the zero-prefix-length records, while if the EXAMPLE zone lags
behind a renumbering of X.EXAMPLE, half of the addresses obtained by
DNS clients will still be up-to-date.
The zero-prefix-length glue records can of course be automatically
generated and/or checked in practice.
Crawford, et al. Standards Track [Page 11]
RFC 2874 IPv6 DNS July 2000
5.1.3. Variations
Several more-or-less arbitrary assumptions are reflected in the above
structure. All of the following choices could have been made
differently, according to someone's notion of convenience or an
agreement between two parties.
First, that site X has chosen to put subnet information in a
separate A6 record rather than incorporate it into each node's A6
records.
Second, that site X is referred to as "SUBSCRIBER-X" by both of
its providers A and B.
Third, that site X chose to indirect its provider information
through A6 records at IP6.X.EXAMPLE containing no significant
bits. An alternative would have been to replicate each subnet
record for each provider.
Fourth, B and E used a slightly different prefix naming convention
between themselves than did A, C and D. Each hierarchical pair of
network entities must arrange this naming between themselves.
Fifth, that the upward prefix referral chain topped out at ALPHA-
TLA.ORG. There could have been another level which assigned the
TLA values and holds A6 records containing those bits.
Finally, the above structure reflects an assumption that address
fields assigned by a given entity are recorded only in A6 records
held by that entity. Those bits could be entered into A6 records in
the lower-level entity's zone instead, thus:
IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET.
IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET.
and so on.
Or the higher-level entities could hold both sorts of A6 records
(with different DNS owner names) and allow the lower-level entities
to choose either mode of A6 chaining. But the general principle of
avoiding data duplication suggests that the proper place to store
assigned values is with the entity that assigned them.
It is possible, but not necessarily recommended, for a zone
maintainer to forego the renumbering support afforded by the chaining
of A6 records and to record entire IPv6 addresses within one zone
file.
Crawford, et al. Standards Track [Page 12]
RFC 2874 IPv6 DNS July 2000
5.2. Reverse Mapping Zones
Supposing that address space assignments in the TLAs with Format
Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
the IP6.ARPA zone would include
$ORIGIN IP6.ARPA.
\[x234500/24] DNAME IP6.ALPHA-TLA.ORG.
\[x267800/24] DNAME IP6.BRAVO-TLA.ORG.
\[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
Eight trailing zero bits have been included in each TLA ID to reflect
the eight reserved bits in the current aggregatable global unicast
addresses format [AGGR].
5.2.1. The TLA level
ALPHA-TLA's assignments to network providers C, D and E are reflected
in the reverse data as follows.
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
\[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET.
\[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET.
5.2.2. The ISP level
The providers A through E carry the following delegation information
in their zone files.
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
\[x2DA/12].IP6.D.NET. DNAME IP6.A.NET.
\[xEB/8].IP6.E.NET. DNAME IP6.B.NET.
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
\[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
Note that some domain names appear in the RDATA of more than one
DNAME record. In those cases, one zone is being used to map multiple
prefixes.
5.2.3. The Site Level
Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
name translations. This domain is now referenced by two different
DNAME records held by two different providers.
Crawford, et al. Standards Track [Page 13]
RFC 2874 IPv6 DNS July 2000
$ORIGIN IP6.X.EXAMPLE.
\[x0001/16] DNAME SUBNET-1
\[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
and so on.
SUBNET-1 need not have been named in a DNAME record; the subnet bits
could have been joined with the interface identifier. But if subnets
are treated alike in both the A6 records and in the reverse zone, it
will always be possible to keep the forward and reverse definition
data for each prefix in one zone.
5.3. Lookups
A DNS resolver looking for a hostname for the address
2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
DNAME records shown above and would form new queries. Assuming that
it began the process knowing servers for IP6.ARPA, but that no server
it consulted provided recursion and none had other useful additional
information cached, the sequence of queried names and responses would
be (all with QCLASS=IN, QTYPE=PTR):
To a server for IP6.ARPA:
QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
Answer:
\[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
To a server for IP6.ALPHA-TLA.ORG:
QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
Answer:
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
To a server for IP6.C.NET.:
QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
Answer:
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
To a server for IP6.A.NET.:
QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
Answer:
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
To a server for IP6.X.EXAMPLE.:
QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
Crawford, et al. Standards Track [Page 14]
RFC 2874 IPv6 DNS July 2000
Answer:
\[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
\[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
All the DNAME (and NS) records acquired along the way can be cached
to expedite resolution of addresses topologically near to this
address. And if another global address of N.X.EXAMPLE were resolved
within the TTL of the final PTR record, that record would not have to
be fetched again.
5.4. Operational Note
In the illustrations in section 5.1, hierarchically adjacent
entities, such as a network provider and a customer, must agree on a
DNS name which will own the definition of the delegated prefix(es).
One simple convention would be to use a bit-string label representing
exactly the bits which are assigned to the lower-level entity by the
higher. For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]".
This would place the A6 record(s) defining the delegated prefix at
exactly the same point in the DNS tree as the DNAME record associated
with that delegation. The cost of this simplification is that the
lower-level zone must update its upward-pointing A6 records when it
is renumbered. This cost may be found quite acceptable in practice.
6. Transition from RFC 1886 and Deployment Notes
When prefixes have been "delegated upward" with A6 records, the
number of DNS resource records required to establish a single IPv6
address increases by some non-trivial factor. Those records will
typically, but not necessarily, come from different DNS zones (which
can independently suffer failures for all the usual reasons). When
obtaining multiple IPv6 addresses together, this increase in RR count
will be proportionally less -- and the total size of a DNS reply
might even decrease -- if the addresses are topologically clustered.
But the records could still easily exceed the space available in a
UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or
SRV query, for example. The possibilities for overall degradation of
performance and reliability of DNS lookups are numerous, and increase
with the number of prefix delegations involved, especially when those
delegations point to records in other zones.
DNS Security [DNSSEC] addresses the trustworthiness of cached data,
which is a problem intrinsic to DNS, but the cost of applying this to
an IPv6 address is multiplied by a factor which may be greater than
the number of prefix delegations involved if different signature
chains must be verified for different A6 records. If a trusted
centralized caching server (as in [TSIG], for example) is used, this
cost might be amortized to acceptable levels. One new phenomenon is
Crawford, et al. Standards Track [Page 15]
RFC 2874 IPv6 DNS July 2000
the possibility that IPv6 addresses may be formed from a A6 records
from a combination of secure and unsecured zones.
Until more deployment experience is gained with the A6 record, it is
recommended that prefix delegations be limited to one or two levels.
A reasonable phasing-in mechanism would be to start with no prefix
delegations (all A6 records having prefix length 0) and then to move
to the use of a single level of delegation within a single zone. (If
the TTL of the "prefix" A6 records is kept to an appropriate duration
the capability for rapid renumbering is not lost.) More aggressively
flexible delegation could be introduced for a subset of hosts for
experimentation.
6.1. Transition from AAAA and Coexistence with A Records
Administrators of zones which contain A6 records can easily
accommodate deployed resolvers which understand AAAA records but not
A6 records. Such administrators can do automatic generation of AAAA
records for all of a zone's names which own A6 records by a process
which mimics the resolution of a hostname to an IPv6 address (see
section 3.1.4). Attention must be paid to the TTL assigned to a
generated AAAA record, which MUST be no more than the minimum of the
TTLs of the A6 records that were used to form the IPv6 address in
that record. For full robustness, those A6 records which were in
different zones should be monitored for changes (in TTL or RDATA)
even when there are no changes to zone for which AAAA records are
being generated. If the zone is secure [DNSSEC], the generated AAAA
records MUST be signed along with the rest of the zone data.
A zone-specific heuristic MAY be used to avoid generation of AAAA
records for A6 records which record prefixes, although such
superfluous records would be relatively few in number and harmless.
Examples of such heuristics include omitting A6 records with a prefix
length less than the largest value found in the zone file, or records
with an address suffix field with a certain number of trailing zero
bits.
On the client side, when looking up and IPv6 address, the order of A6
and AAAA queries MAY be configurable to be one of: A6, then AAAA;
AAAA, then A6; A6 only; or both in parallel. The default order (or
only order, if not configurable) MUST be to try A6 first, then AAAA.
If and when the AAAA becomes deprecated a new document will change
the default.
The guidelines and options for precedence between IPv4 and IPv6
addresses are specified in [TRANS]. All mentions of AAAA records in
that document are henceforth to be interpreted as meaning A6 and/or
AAAA records in the order specified in the previous paragraph.
Crawford, et al. Standards Track [Page 16]
RFC 2874 IPv6 DNS July 2000
6.2. Transition from Nibble Labels to Binary Labels
Implementations conforming to RFC 1886 [AAAA] perform reverse lookups
as follows:
An IPv6 address is represented as a name in the IP6.INT domain by
a sequence of nibbles separated by dots with the suffix
".IP6.INT". The sequence of nibbles is encoded in reverse order,
i.e. the low-order nibble is encoded first, followed by the next
low-order nibble and so on. Each nibble is represented by a
hexadecimal digit. For example, a name for the address
2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section
5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
Implementations conforming to this specification will perform a
lookup of a binary label in IP6.ARPA as specified in Section 3.2. It
is RECOMMENDED that for a transition period implementations first
lookup the binary label in IP6.ARPA and if this fails try to lookup
the 'nibble' label in IP6.INT.
7. Security Considerations
The signing authority [DNSSEC] for the A6 records which determine an
IPv6 address is distributed among several entities, reflecting the
delegation path of the address space which that address occupies.
DNS Security is fully applicable to bit-string labels and DNAME
records. And just as in IPv4, verification of name-to-address
mappings is logically independent of verification of address-to-name
mappings.
With or without DNSSEC, the incomplete but non-empty address set
scenario of section 3.1.4 could be caused by selective interference
with DNS lookups. If in some situation this would be more harmful
than complete DNS failure, it might be mitigated on the client side
by refusing to act on an incomplete set, or on the server side by
listing all addresses in A6 records with prefix length 0.
8. IANA Considerations
The A6 resource record has been assigned a Type value of 38.
Crawford, et al. Standards Track [Page 17]
RFC 2874 IPv6 DNS July 2000
9. Acknowledgments
The authors would like to thank the following persons for valuable
discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, Randy
Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont,
Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden,
Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
10. References
[AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6, RFC 1886, December 1995.
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6
Aggregatable Global Unicast Address Format", RFC 2374, July
1998.
[BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999.
[DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[DNSIS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
Security Extensions", RFC 2535, March 1999.
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
[RENUM2] Ferguson, P. and H. Berkowitz, "Network Renumbering
Overview: Why would I want it and what is it anyway?", RFC
2071, January 1997.
[RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, February 1997.
Crawford, et al. Standards Track [Page 18]
RFC 2874 IPv6 DNS July 2000
[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
11. Authors' Addresses
Matt Crawford
Fermilab
MS 368
PO Box 500
Batavia, IL 60510
USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: huitema@microsoft.com
Crawford, et al. Standards Track [Page 19]
RFC 2874 IPv6 DNS July 2000
12. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Crawford, et al. Standards Track [Page 20]
|