-
Notifications
You must be signed in to change notification settings - Fork 0
/
IPFF-DNS-RFC-draft.txt
199 lines (141 loc) · 7.77 KB
/
IPFF-DNS-RFC-draft.txt
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
A.Eromenko
Category: Proposed Standard November 2015
DNS Extensions to Support IP Version 5
(a.k.a Internet Protocol "Five Fields")
Specification Draft
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) by Alexey Eromenko (2015), based on RFC-3596 of
The Internet Society (2003). All Rights Reserved.
Abstract
This document defines the changes that need to be made to the Domain
Name System (DNS) to support hosts running IP version 5 (IPFF). The
changes include a resource record type to store an IPFF address, a
domain to support lookups based on an IPFF address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing. The extensions are designed
to be compatible with existing applications and, in particular, DNS
implementations themselves.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. New resource record definition and domain. . . . . . . . . . . 2
2.1. AA record type . . . . . . . . . . . . . . . . . . . . . 3
2.2. AA data format . . . . . . . . . . . . . . . . . . . . . 3
2.3. AA query . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4. Textual format of AA records . . . . . . . . . . . . . . 3
2.5. Reverse Lookups and PTR records. . . . . . . . . . . . . 3
3. Modifications to existing query types. . . . . . . . . . . . . 4
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 4
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Contacts . . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Current support for the storage of Internet addresses in the Domain
Name System (DNS) cannot easily be extended to support IPFF
addresses [IPFF-Addressing-RFC-draft] since applications assume that
address queries return 32-bit IPv4 or 128-bit IPv6 addresses only.
To support the storage of IPFF addresses in the DNS, this document
defines the following extensions:
o A resource record type is defined to map a domain name to an
IPFF address.
o A domain is defined to support lookups based on address.
o Existing queries that perform additional section processing to
locate IPFF addresses are redefined to perform additional
section processing on both IPv4 and IPFF addresses.
The changes are designed to be compatible with existing software.
The existing support for IPv4 addresses is retained.
The IP protocol version used for querying resource records is
independent of the protocol version of the resource records; e.g.,
IPv4 or IPv6 transport can be used to query IPFF records and vice
versa.
2. New resource record definition and domain
A record type is defined to store a host's IPFF address. A host that
has more than one IPFF address must have more than one such record.
AA explanation:
"AA record" was chosen, as it mimics the idea behind "A" being a
32-bit value of IPv4, compared to "AAAA" (Quad A) being a 128-bit
value of IPv6. Since internal representation of 50-bit addresses in
IPFF are pre-padded to full 64-bits, double A, or "AA" seems
appropriate.
The proposed draft value is to be determined...
2.1 AA record type
The AA resource record type is a record specific to the Internet
class that stores a single IPFF address.
2.2 AA data format
A 50 bit IPFF address is encoded in the data portion of an AA
resource record in network byte order (high-order byte first),
pre-padded by a set of 14-bit zeros, forming an internal 64-bit data
structure.
2.3 AA query
An AA query for a specified domain name in the Internet class
returns all associated AA resource records in the answer section of
a response.
A type AA query does not trigger additional section processing.
2.4 Textual format of AA records
The textual representation of the data portion of the AA resource
record used in a master database file is the textual representation
of an IPFF address as defined in [IPFF-Addressing-RFC-draft].
2.5 Reverse Lookups and PTR records
A special domain is defined to look up a record given an IPFF
address. The intent of this domain is to provide a way of mapping an
IPFF address to a host name, although it may be used for other
purposes as well. The domain is proposed to be IP5.ARPA.
An IPFF address is represented as a name in the IP5.ARPA domain by a
sequence of decimal digits separated by dots with the suffix
".IP5.ARPA". The sequence of digits is encoded in reverse order,
i.e., the low-order digit is encoded first, followed by the next
low-order digit and so on.
For example, the reverse lookup domain name corresponding to the
address
382.21.968.2.133
would be
3.3.1.2.0.0.8.6.9.1.2.0.2.8.3.IP5.ARPA
3. Modifications to existing query types
All existing query types that perform type A additional section
processing, i.e., name server (NS), location of services (SRV) and
mail exchange (MX) query types, must be redefined to perform both
type A and type AA additional section processing. These
definitions mean that a name server must add any relevant IPv4
addresses and any relevant IPFF addresses available locally to the
additional section of a response when processing any one of the above
queries.
4. Security Considerations
This specification is not believed to cause any new security
problems, nor to solve any existing ones.
Acknowledgments
Thanks to all previous DNS and DNSv6 developers, paricularly those
written RFC-3596 (DNSv6).
Authors' Contacts
Alexey Eromenko
Israel
Skype: Fenix_NBK_
EMail: [email protected]
Full Copyright Statement
Copyright (C) Alexey Eromenko (2015), based on the previous work of
The Internet Society (2003). 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 assignees.
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.