Internet DRAFT - draft-ietf-sip-sippdns
draft-ietf-sip-sippdns
Network Working Group C. Huitema (INRIA)
INTERNET-DRAFT S. Thomson (Bellcore)
<draft-ietf-sip-sippdns-00.txt> October 1993
Extensions to DNS to support SIPP
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract
SIPP is an internet protocol intended as the replacement for IP
version 4. SIPP addresses differ from IP addresses in that they are
at least 64 bits long and may be extended in multiples of 64 bits.
This specification describes the modifications that need to be made
to DNS to store SIPP addresses and to support the transition from use
of IP to use of SIPP.
1. INTRODUCTION
SIPP is an internet protocol intended as the replacement for IP ver-
sion 4. SIPP addresses differ from IP addresses in that they are at
least 64 bits long and may be extended in multiples of 64 bits. This
specification describes the modifications that need to be made to DNS
to store SIPP addresses and support the transition from use of IP to
SIPP WG, Expires April 30, 1994 [Page 1]
INTERNET-DRAFT SIPP DNS October 1993
use of SIPP.
In this specification, we introduce a new resource record (RR) type
to store a SIPP address and a new domain to form inverse lookups on
an address. We also describe modifications to existing RR definitions
and resolvers/applications to support IP, SIPP and dual-stack hosts
during transition. The transition of DNS itself from being an IP-
only service to supporting both IP and SIPP is also discussed.
2. Storing SIPP Addresses
2.1. ASEQ type value
The ASEQ RR is a new Internet-specific RR added to store a SIPP
address. Pending assignment by IANA, the provisional type value used
is 64.
2.2. ASEQ data format
SIPP addresses are encoded as a sequence of 64-bit words in the RDATA
section of a record:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ ASEQ /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ASEQ One or more 64-bit words containing a SIPP address
Hosts that have multiple SIPP addresses will have multiple ASEQ RRs.
Type ASEQ RRs cause no additional section processing. The RDATA sec-
tion of an ASEQ line in a master file is a SIPP address expressed in
its textual format, yet to be defined. In this draft, an address is
SIPP WG, Expires April 30, 1994 [Page 2]
INTERNET-DRAFT SIPP DNS October 1993
written as a sequence of hex digits, separated by colons after every
4 digits, e.g. 0bcd:0000:1234:5678.
2.3. Inverse Domain
A special domain is needed to map a SIPP address to a hostname.
Pending assignment by IANA, the domain is provisionally rooted at
SIPP-ADDR.ARPA.
Domain names in the SIPP-ADDR.ARPA domain have a variable number of
labels with suffix "SIPP-ADDR.ARPA". The low-order 32-bits of a SIPP
address are represented by four labels, one per octet. The labels are
expressed as a character string for a decimal value in the range 0-FF
with leading zeroes omitted except in the case of a null value which
is represented by a single zero. The higher order parts of the
address have labels that represent two octets each. Each label is
expressed as a character string for a hex value in the range 0-FFFF
with leading zeroes omitted except in the case of a null value which
is represented by a single zero. For example, an address in hex of
0bcd:0000:8060:2105
would be represented by
5.33.96.128.0.bcd.SIP-ADDR.ARPA
3. IP-to-SIPP Transition
During transition, some hosts will have IP addresses only, others
SIPP addresses only and others both addresses. DNS must support all
three cases efficiently. Moreover, some name servers will have been
modified to support SIPP and IP address records, and others not. This
section discusses the modifications required to support the use of
two different address spaces efficiently. It also discusses how tran-
sition of the name service itself is expected to take place and the
assumptions made about existing implementations for this to work.
3.1. Resolver/Application Extensions
Since it is in general not known whether a host is IP or SIPP before
SIPP WG, Expires April 30, 1994 [Page 3]
INTERNET-DRAFT SIPP DNS October 1993
its address is looked up in DNS, resolvers or application alibraries
must be modified to query for both types of address. This change
affects both full-service resolvers and stub resolvers (or the appli-
cation libraries that use them). In particular, full-service
resolvers need to determine the SIPP or IP addresses of name servers
to be contacted during a lookup.
3.2. Modifications to other RR types
To enable efficient operation, all RR types that perform type A addi-
tional section processing, i.e. NS, MX and MB record types, must be
redefined to perform both type A and type ASEQ additional section
processing. Additional section processing is thus useful whether a
host named in one of these records has an IP address, a SIPP address
or both.
3.3. DNS Transition
During transition, there will be name servers modified to support
both SIPP and IP address records and unmodified name servers that
store IP addresses only. Any zone that has a SIPP host must have a
name server that stores SIPP records. IP-only zones may or may not
have a SIPP-modified name server. Parents of SIPP-modified name
servers should be converted to store SIPP address records as quickly
as possible (if they have not been converted already) so that they
cache these records when the opportunity arises.
3.4. Assumptions Made
This transition scheme assumes existing IP name servers have been
implemented to accept requests for RR types that they do not recog-
nize, and that IP resolvers ignore all RR types received that they
do not understand. In particular, an unmodified resolver that
receives a SIPP address as part of additional section processing
should ignore it.
SIPP WG, Expires April 30, 1994 [Page 4]
