+3457. [protocol] Add ILNP records (NID, LP, L32, L64). [RT #31836]
+
3456. [port] g++47: aft fails to compile. [RT #32012]
3455. [contrib] queryperf: fix getopt option list. [RT #32338]
--- /dev/null
+#!/bin/sh
+#
+# Copyright (C) 2005-2007, 2012 Internet Systems Consortium, Inc. ("ISC")
+#
+# Permission to use, copy, modify, and/or distribute this software for any
+# purpose with or without fee is hereby granted, provided that the above
+# copyright notice and this permission notice appear in all copies.
+#
+# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+# PERFORMANCE OF THIS SOFTWARE.
+
+# $Id: clean.sh,v 1.6 2007/09/26 03:22:44 marka Exp $
+
+#
+# Clean up after tests.
+#
+
+rm -f dig.out.*
+rm -f */named.memstats
+rm -f */named.conf
+rm -f */named.run
--- /dev/null
+# this server runs named with only one worker thread
+-m record,size,mctx -c named.conf -d 99 -g -T clienttest -n 1
\ No newline at end of file
--- /dev/null
+/*
+ * Copyright (C) 2005-2007 Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/* $Id: named.conf,v 1.5 2007/06/19 23:47:06 tbox Exp $ */
+
+options {
+ query-source address 10.53.0.1;
+ notify-source 10.53.0.1;
+ transfer-source 10.53.0.1;
+ recursion no;
+ additional-from-auth no;
+ port 5300;
+ pid-file "named.pid";
+ listen-on { 10.53.0.1; };
+ listen-on-v6 { none; };
+ notify no;
+ minimal-responses yes;
+};
+
+include "../../common/rndc.key";
+
+controls {
+ inet 10.53.0.1 port 9953 allow { any; } keys { rndc_key; };
+};
+
+zone "rt.example" {
+ type master;
+ file "rt.db";
+};
+
+zone "naptr.example" {
+ type master;
+ file "naptr.db";
+};
+
+zone "rt2.example" {
+ type master;
+ file "rt2.db";
+};
+
+zone "naptr2.example" {
+ type master;
+ file "naptr2.db";
+};
+
+zone "nid.example" {
+ type master;
+ file "nid.db";
+};
--- /dev/null
+/*
+ * Copyright (C) 2005-2007 Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/* $Id: named.conf,v 1.5 2007/06/19 23:47:06 tbox Exp $ */
+
+options {
+ query-source address 10.53.0.1;
+ notify-source 10.53.0.1;
+ transfer-source 10.53.0.1;
+ recursion no;
+ additional-from-auth no;
+ port 5300;
+ pid-file "named.pid";
+ listen-on { 10.53.0.1; };
+ listen-on-v6 { none; };
+ notify no;
+ minimal-responses no;
+};
+
+include "../../common/rndc.key";
+
+controls {
+ inet 10.53.0.1 port 9953 allow { any; } keys { rndc_key; };
+};
+
+zone "rt.example" {
+ type master;
+ file "rt.db";
+};
+
+zone "naptr.example" {
+ type master;
+ file "naptr.db";
+};
+
+zone "rt2.example" {
+ type master;
+ file "rt2.db";
+};
+
+zone "naptr2.example" {
+ type master;
+ file "naptr2.db";
+};
+
+zone "nid.example" {
+ type master;
+ file "nid.db";
+};
--- /dev/null
+$TTL 86400
+@ IN SOA ns1 hostmaster ( 2 8H 2H 4W 1D );
+ NS ns1
+ns1 A 127.0.0.0
+
+nap IN NAPTR 50 50 "S" "SIPS+D2T" "" server
+server SRV 0 0 5061 server
+server A 192.168.2.9
+server AAAA 192::9
--- /dev/null
+$TTL 86400
+@ IN SOA ns1 hostmaster ( 2 8H 2H 4W 1D );
+ NS ns1
+ns1 A 127.0.0.0
+
+nap IN NAPTR 50 50 "S" "SIPS+D2T" "" server.hang3a.zone.
+www AAAA 192::99
+www A 192.168.2.99
+www X25 100099
--- /dev/null
+$TTL 86400
+@ IN SOA ns1 hostmaster ( 2 8H 2H 4W 1D );
+ NS ns1
+ns1 A 127.0.0.0
+
+ns1 NID 2 0:0:0:0
+ns1 L64 2 0:0:0:0
+ns1 L32 2 0.0.0.0
+nid2 NID 2 0:0:0:1
+nid2 LP 2 ns1
--- /dev/null
+$TTL 86400
+@ IN SOA ns1 hostmaster ( 2 8H 2H 4W 1D );
+ NS ns1
+ns1 A 127.0.0.0
+
+rt RT 2 www
+www AAAA 192::99
+www A 192.168.2.99
+www X25 100099
--- /dev/null
+$TTL 86400
+@ IN SOA ns1 hostmaster ( 2 8H 2H 4W 1D );
+ NS ns1
+ns1 A 127.0.0.0
+
+rt RT 2 www.hang3b.zone.
+server SRV 0 0 5061 server
+server A 192.168.2.9
+server AAAA 192::9
--- /dev/null
+#!/bin/sh
+#
+# Copyright (C) 2012 Internet Systems Consortium, Inc. ("ISC")
+#
+# Permission to use, copy, modify, and/or distribute this software for any
+# purpose with or without fee is hereby granted, provided that the above
+# copyright notice and this permission notice appear in all copies.
+#
+# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+# PERFORMANCE OF THIS SOFTWARE.
+
+cp -f ns1/named1.conf ns1/named.conf
--- /dev/null
+#!/bin/sh
+#
+# Copyright (C) 2005-2007, 2011, 2012 Internet Systems Consortium, Inc. ("ISC")
+#
+# Permission to use, copy, modify, and/or distribute this software for any
+# purpose with or without fee is hereby granted, provided that the above
+# copyright notice and this permission notice appear in all copies.
+#
+# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+# PERFORMANCE OF THIS SOFTWARE.
+
+# $Id: tests.sh,v 1.7 2011/11/06 23:46:40 tbox Exp $
+
+SYSTEMTESTTOP=..
+. $SYSTEMTESTTOP/conf.sh
+
+status=0
+n=0
+
+dotests() {
+ n=`expr $n + 1`
+ echo "I:test with RT, single zone ($n)"
+ ret=0
+ $DIG -t RT rt.rt.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1
+ if [ $ret -eq 1 ] ; then
+ echo "I: failed"; status=1
+ fi
+
+ n=`expr $n + 1`
+ echo "I:test with RT, two zones ($n)"
+ ret=0
+ $DIG -t RT rt.rt2.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1
+ if [ $ret -eq 1 ] ; then
+ echo "I: failed"; status=1
+ fi
+
+ n=`expr $n + 1`
+ echo "I:test with NAPTR, single zone ($n)"
+ ret=0
+ $DIG -t NAPTR nap.naptr.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1
+ if [ $ret -eq 1 ] ; then
+ echo "I: failed"; status=1
+ fi
+
+ n=`expr $n + 1`
+ echo "I:test with NAPTR, two zones ($n)"
+ ret=0
+ $DIG -t NAPTR nap.hang3b.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1
+ if [ $ret -eq 1 ] ; then
+ echo "I: failed"; status=1
+ fi
+
+ n=`expr $n + 1`
+ echo "I:test with LP ($n)"
+ ret=0
+ $DIG -t LP nid2.nid.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1
+ if [ $minimal = no ] ; then
+ grep "L64" dig.out.$n > /dev/null || ret=1
+ grep "L32" dig.out.$n > /dev/null || ret=1
+ else
+ grep "L64" dig.out.$n > /dev/null && ret=1
+ grep "L32" dig.out.$n > /dev/null && ret=1
+ fi
+ if [ $ret -eq 1 ] ; then
+ echo "I: failed"; status=1
+ fi
+
+ n=`expr $n + 1`
+ echo "I:test with NID ($n)"
+ ret=0
+ $DIG -t NID ns1.nid.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1
+ if [ $minimal = no ] ; then
+ # change && to || when we support NID additional processing
+ grep "L64" dig.out.$n > /dev/null && ret=1
+ grep "L32" dig.out.$n > /dev/null && ret=1
+ else
+ grep "L64" dig.out.$n > /dev/null && ret=1
+ grep "L32" dig.out.$n > /dev/null && ret=1
+ fi
+ if [ $ret -eq 1 ] ; then
+ echo "I: failed"; status=1
+ fi
+
+ n=`expr $n + 1`
+ echo "I:test with NID + LP ($n)"
+ ret=0
+ $DIG -t NID nid2.nid.example @10.53.0.1 -p 5300 > dig.out.$n || ret=1
+ if [ $minimal = no ] ; then
+ # change && to || when we support NID additional processing
+ grep "LP" dig.out.$n > /dev/null && ret=1
+ grep "L64" dig.out.$n > /dev/null && ret=1
+ grep "L32" dig.out.$n > /dev/null && ret=1
+ else
+ grep "LP" dig.out.$n > /dev/null && ret=1
+ grep "L64" dig.out.$n > /dev/null && ret=1
+ grep "L32" dig.out.$n > /dev/null && ret=1
+ fi
+ if [ $ret -eq 1 ] ; then
+ echo "I: failed"; status=1
+ fi
+}
+
+echo "I:testing with 'minimal-responses yes;'"
+minimal=yes
+dotests
+
+echo "I:reconfiguring server"
+cp ns1/named2.conf ns1/named.conf
+$RNDC -c ../common/rndc.conf -s 10.53.0.1 -p 9953 reconfig 2>&1 | sed 's/^/I:ns1 /'
+sleep 2
+
+echo "I:testing with 'minimal-responses no;'"
+minimal=no
+dotests
+
+exit $status
# The "stress" test is not run by default since it creates enough
# load on the machine to make it unusable to other users.
# v6synth
-SUBDIRS="acl allow_query addzone autosign builtin cacheclean checkconf
- checknames checkzone database dlv dlvauto dlz dlzexternal
- dname dns64 dnssec ecdsa forward glue gost ixfr limits
- logfileconfig lwresd masterfile masterformat metadata notify
- nsupdate pending pkcs11 resolver rndc rpz rrsetorder sortlist
- smartsign staticstub stub tkey tsig tsiggss unknown upforwd
- views wildcard xfer xferquota zonechecks"
+SUBDIRS="acl additional allow_query addzone autosign builtin
+ cacheclean checkconf checknames checkzone database dlv
+ dlvauto dlz dlzexternal dname dns64 dnssec ecdsa forward
+ glue gost ixfr limits logfileconfig lwresd masterfile
+ masterformat metadata notify nsupdate pending pkcs11
+ resolver rndc rpz rrsetorder sortlist smartsign staticstub
+ stub tkey tsig tsiggss unknown upforwd views wildcard xfer
+ xferquota zonechecks"
# PERL will be an empty string if no perl interpreter was found.
PERL=@PERL@
1b177615d466f6c4b71c216a50292bd5
8c9ebdd2f74e38fe51ffd48c43326cbc )
+nid NID 10 0014:4fff:ff20:ee64
+
+l32 L32 10 1.2.3.4
+
+l64 L64 10 0014:4fff:ff20:ee64
+
+lp LP 10 example.net.
+
; type 255
; TSIG is a meta-type and should never occur in master files.
EOF
gpos02.example. 3600 IN GPOS "" "" ""
hinfo01.example. 3600 IN HINFO "Generic PC clone" "NetBSD-1.4"
hinfo02.example. 3600 IN HINFO "PC" "NetBSD"
-hip1.example. 3600 IN HIP 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
+hip1.example. 3600 IN HIP 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
hip2.example. 3600 IN HIP 2 200100107B1A74DF365639CC39F1D578 AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQb1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D rvs.example.com.
isdn01.example. 3600 IN ISDN "isdn-address"
isdn02.example. 3600 IN ISDN "isdn-address" "subaddress"
kx02.example. 3600 IN KX 10 .
loc01.example. 3600 IN LOC 60 9 0.000 N 24 39 0.000 E 10.00m 20m 2000m 20m
loc02.example. 3600 IN LOC 60 9 0.000 N 24 39 0.000 E 10.00m 20m 2000m 20m
+l32.example. 3600 IN L32 10 1.2.3.4
+l64.example. 3600 IN L64 10 14:4fff:ff20:ee64
+lp.example. 3600 IN LP 10 example.net.
+nid.example. 3600 IN NID 10 14:4fff:ff20:ee64
mb01.example. 3600 IN MG madname.example.
mb02.example. 3600 IN MG .
mg01.example. 3600 IN MG mgmname.example.
kx02.example. 3600 IN KX 10 .
loc01.example. 3600 IN LOC 60 9 0.000 N 24 39 0.000 E 10.00m 20m 2000m 20m
loc02.example. 3600 IN LOC 60 9 0.000 N 24 39 0.000 E 10.00m 20m 2000m 20m
+l32.example. 3600 IN L32 10 1.2.3.4
+l64.example. 3600 IN L64 10 14:4fff:ff20:ee64
+lp.example. 3600 IN LP 10 example.net.
+nid.example. 3600 IN NID 10 14:4fff:ff20:ee64
mb01.example. 3600 IN MG madname.example.
mb02.example. 3600 IN MG .
mg01.example. 3600 IN MG mgmname.example.
5933: Use of GOST Signature Algorithms in DNSKEY
and RRSIG Resource Records for DNSSEC
6303: Locally Served DNS Zones
+6742: DNS Resource Records for the
+ Identifier-Locator Network Protocol (ILNP)
+
--- /dev/null
+
+
+
+
+
+
+Internet Research Task Force (IRTF) RJ Atkinson
+Request for Comments: 6742 Consultant
+Category: Experimental SN Bhatti
+ISSN: 2070-1721 U. St Andrews
+ S. Rose
+ US NIST
+ November 2012
+
+
+ DNS Resource Records for the
+ Identifier-Locator Network Protocol (ILNP)
+
+Abstract
+
+ This note describes additional optional resource records for use with
+ the Domain Name System (DNS). These optional resource records are
+ for use with the Identifier-Locator Network Protocol (ILNP). This
+ document is a product of the IRTF Routing Research Group.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Research Task
+ Force (IRTF). The IRTF publishes the results of Internet-related
+ research and development activities. These results might not be
+ suitable for deployment. This RFC represents the individual
+ opinion(s) of one or more members of the Routing Research Group of
+ the Internet Research Task Force (IRTF). Documents approved for
+ publication by the IRSG are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6742.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson, et al. Experimental [Page 1]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+ This document may not be modified, and derivative works of it may not
+ be created, except to format it for publication as an RFC or to
+ translate it into languages other than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Document Roadmap ...........................................4
+ 1.2. Terminology ................................................5
+ 2. New Resource Records ............................................5
+ 2.1. The NID Resource Record ....................................5
+ 2.2. The L32 Resource Record ....................................7
+ 2.3. The L64 Resource Record ...................................10
+ 2.4. The LP Resource Record ....................................12
+ 3. Deployment Example .............................................15
+ 3.1. Use of ILNP Records .......................................15
+ 3.2. Additional Section Processing .............................16
+ 4. Security Considerations ........................................17
+ 5. IANA Considerations ............................................17
+ 6. References .....................................................17
+ 6.1. Normative References ......................................17
+ 6.2. Informative References ....................................18
+ 7. Acknowledgements ...............................................20
+
+1. Introduction
+
+ This document is part of the ILNP document set, which has had
+ extensive review within the IRTF Routing RG. ILNP is one of the
+ recommendations made by the RG Chairs. Separately, various refereed
+ research papers on ILNP have also been published during this decade.
+ So, the ideas contained herein have had much broader review than the
+ IRTF Routing RG. The views in this document were considered
+ controversial by the Routing RG, but the RG reached a consensus that
+ the document still should be published. The Routing RG has had
+ remarkably little consensus on anything, so virtually all Routing RG
+ outputs are considered controversial.
+
+
+
+Atkinson, et al. Experimental [Page 2]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+ At present, the Internet research and development community is
+ exploring various approaches to evolving the Internet Architecture to
+ solve a variety of issues including, but not limited to, scalability
+ of inter-domain routing [RFC4984]. A wide range of other issues
+ (e.g., site multihoming, node multihoming, site/subnet mobility, node
+ mobility) are also active concerns at present. Several different
+ classes of evolution are being considered by the Internet research
+ and development community. One class is often called "Map and
+ Encapsulate", where traffic would be mapped and then tunnelled
+ through the inter-domain core of the Internet. Another class being
+ considered is sometimes known as "Identifier/Locator Split". This
+ document relates to a proposal that is in the latter class of
+ evolutionary approaches.
+
+ The Identifier-Locator Network Protocol (ILNP) was developed to
+ explore a possible evolutionary direction for the Internet
+ Architecture. A description of the ILNP architecture is available in
+ a separate document [RFC6740]. Implementation and engineering
+ details are largely isolated into a second document [RFC6741].
+
+ The Domain Name System (DNS) is the standard way that Internet nodes
+ locate information about addresses, mail exchangers, and other data
+ relating to remote Internet nodes [RFC1034] [RFC1035].
+
+ More recently, the IETF has defined standards-track security
+ extensions to the DNS [RFC4033]. These security extensions can be
+ used to authenticate signed DNS data records and can be used to store
+ signed public keys in the DNS. Further, the IETF has defined a
+ standards-track approach to enable secure dynamic update of DNS
+ records over the network [RFC3007].
+
+ This document defines several new optional data resource records.
+ This note specifies the syntax and other items required for
+ independent implementations of these DNS resource records. The
+ reader is assumed to be familiar with the basics of DNS, including
+ familiarity with [RFC1034] [RFC1035].
+
+ The concept of using DNS for rendezvous with mobile nodes or mobile
+ networks has been proposed earlier, more than once, independently, by
+ several other researchers; for example, please see [SB00], [SBK01],
+ and [PHG02].
+
+
+
+
+
+
+
+
+
+
+Atkinson, et al. Experimental [Page 3]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+1.1. Document Roadmap
+
+ This document describes defines additional DNS resource records that
+ support ILNP.
+
+ The ILNP architecture can have more than one engineering
+ instantiation. For example, one can imagine a "clean-slate"
+ engineering design based on the ILNP architecture. In separate
+ documents, we describe two specific engineering instances of ILNP.
+ The term "ILNPv6" refers precisely to an instance of ILNP that is
+ based upon, and backwards compatible with, IPv6. The term "ILNPv4"
+ refers precisely to an instance of ILNP that is based upon, and
+ backwards compatible with, IPv4.
+
+ Many engineering aspects common to both ILNPv4 and ILNPv6 are
+ described in [RFC6741]. A full engineering specification for either
+ ILNPv6 or ILNPv4 is beyond the scope of this document.
+
+ Readers are referred to other related ILNP documents for details not
+ described here:
+
+ a) [RFC6740] is the main architectural description of ILNP, including
+ the concept of operations.
+
+ b) [RFC6741] describes engineering and implementation considerations
+ that are common to both ILNPv4 and ILNPv6.
+
+ c) [RFC6743] defines a new ICMPv6 Locator Update message used by an
+ ILNP node to inform its correspondent nodes of any changes to its
+ set of valid Locators.
+
+ d) [RFC6744] defines a new IPv6 Nonce Destination Option used by
+ ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by
+ inclusion within the initial packets of an ILNP session) that the
+ node is operating in the ILNP mode and (2) to prevent off-path
+ attacks against ILNP ICMP messages. This Nonce is used, for
+ example, with all ILNP ICMPv6 Locator Update messages that are
+ exchanged among ILNP correspondent nodes.
+
+ e) [RFC6745] defines a new ICMPv4 Locator Update message used by an
+ ILNP node to inform its correspondent nodes of any changes to its
+ set of valid Locators.
+
+ f) [RFC6746] defines a new IPv4 Nonce Option used by ILNPv4 nodes to
+ carry a security nonce to prevent off-path attacks against ILNP
+ ICMP messages and also defines a new IPv4 Identifier Option used
+ by ILNPv4 nodes.
+
+
+
+
+Atkinson, et al. Experimental [Page 4]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+ g) [RFC6747] describes extensions to Address Resolution Protocol
+ (ARP) for use with ILNPv4.
+
+ h) [RFC6748] describes optional engineering and deployment functions
+ for ILNP. These are not required for the operation or use of ILNP
+ and are provided as additional options.
+
+1.2. Terminology
+
+ In this document, the term "ILNP-aware" applied to a DNS component
+ (either authoritative server or cache) is used to indicate that the
+ component attempts to include other ILNP RRTypes to the Additional
+ section of a DNS response to increase performance and reduce the
+ number of follow-up queries for other ILNP RRTypes. These other
+ RRsets MAY be added to the Additional section if space permits and
+ only when the QTYPE equals NID, L64, L32, or LP. There is no method
+ for a server to signal that it is ILNP-aware.
+
+ 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 [RFC2119].
+
+2. New Resource Records
+
+ This document specifies several new and closely related DNS data
+ resource records (RRs). These new RR types have the mnemonics "NID",
+ "L32", "L64", and "LP". These RR types are associated with a Fully
+ Qualified Domain Name (FQDN) that is hereafter called the "owner
+ name". These are part of work on the Identifier-Locator Network
+ Protocol (ILNP) [RFC6740].
+
+ For clarity, throughout this section of this document, the "RDATA"
+ subsections specify the on-the-wire format for these records, while
+ the "Presentation Format" subsections specify the human-readable
+ format used in a DNS configuration file (i.e., "master file" as
+ defined by RFC 1035, Section 5.1).
+
+2.1. The NID Resource Record
+
+ The Node Identifier (NID) DNS resource record (RR) is used hold
+ values for Node Identifiers that will be used for ILNP-capable nodes.
+
+ NID records are present only for ILNP-capable nodes. This
+ restriction is important; ILNP-capable nodes use the presence of NID
+ records in the DNS to learn that a correspondent node is also ILNP-
+ capable. While erroneous NID records in the DNS for a node that is
+ not ILNP-capable would not prevent communication, such erroneous DNS
+ records could increase the delay at the start of an IP session.
+
+
+
+Atkinson, et al. Experimental [Page 5]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+ A given owner name may have zero or more NID records at a given time.
+ In normal operation, nodes that support the Identifier-Locator
+ Network Protocol (ILNP) will have at least one valid NID record.
+
+ The type value for the NID RR type is 104.
+
+ The NID RR is class independent.
+
+ The NID RR has no special Time to Live (TTL) requirements.
+
+2.1.1. NID RDATA Wire Format
+
+ The RDATA for an NID RR consists of:
+
+ - a 16-bit Preference field
+ - a 64-bit NodeID field
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preference | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | NodeID |
+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1.1.1. The Preference Field
+
+ The <Preference> field contains a 16-bit unsigned integer in network
+ byte order that indicates the owner name's relative preference for
+ this NID record among other NID records associated with this owner
+ name. Lower Preference values are preferred over higher Preference
+ values.
+
+2.1.1.2. The NodeID Field
+
+ The NodeID field is an unsigned 64-bit value in network byte order.
+ It complies with the syntactic rules of IPv6 interface identifiers
+ [RFC4291], Section 2.5.1, but has slightly different semantics.
+ Unlike IPv6 interface identifiers, which are bound to a specific
+ *interface* of a specific node, NodeID values are bound to a specific
+ *node*, and they MAY be used with *any interface* of that node.
+
+
+
+
+
+
+
+
+Atkinson, et al. Experimental [Page 6]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+2.1.2. NID RR Presentation Format
+
+ The presentation of the format of the RDATA portion is as follows:
+
+ - The Preference field MUST be represented as a 16-bit unsigned
+ decimal integer.
+
+ - The NodeID field MUST be represented using the same syntax (i.e.,
+ groups of 4 hexadecimal digits, with each group separated by a
+ colon) that is already used for DNS AAAA records (and also used for
+ IPv6 interface IDs).
+
+ - The NodeID value MUST NOT be in the 'compressed' format (e.g.,
+ using "::") that is defined in RFC 4291, Section 2.2 (2). This
+ restriction exists to avoid confusion with 128-bit IPv6 addresses,
+ because the NID is a 64-bit field.
+
+2.1.3. NID RR Examples
+
+ An NID record has the following logical components:
+
+ <owner-name> IN NID <Preference> <NodeID>
+
+ In the above, <owner-name> is the owner name string, <Preference> is
+ an unsigned 16-bit value, and <NodeID> is an unsigned 64-bit value.
+
+ host1.example.com. IN NID 10 0014:4fff:ff20:ee64
+ host1.example.com. IN NID 20 0015:5fff:ff21:ee65
+ host2.example.com. IN NID 10 0016:6fff:ff22:ee66
+
+ As NodeID values use the same syntax as IPv6 interface identifiers,
+ when displayed for human readership, the NodeID values are presented
+ in the same hexadecimal format as IPv6 interface identifiers. This
+ is shown in the example above.
+
+2.1.4. Additional Section Processing
+
+ To improve performance, ILNP-aware DNS servers and DNS resolvers MAY
+ attempt to return all L32, L64, and LP records for the same owner
+ name of the NID RRset in the Additional section of the response, if
+ space permits.
+
+2.2. The L32 Resource Record
+
+ An L32 DNS RR is used to hold 32-bit Locator values for
+ ILNPv4-capable nodes.
+
+
+
+
+
+Atkinson, et al. Experimental [Page 7]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+ L32 records are present only for ILNPv4-capable nodes. This
+ restriction is important; ILNP-capable nodes use the presence of L32
+ records in the DNS to learn that a correspondent node is also
+ ILNPv4-capable. While erroneous L32 records in the DNS for a node
+ that is not ILNP-capable would not prevent communication, such
+ erroneous DNS records could increase the delay at the start of an IP
+ session.
+
+ A given owner name might have zero or more L32 values at a given
+ time. An ILNPv4-capable host SHOULD have at least 1 Locator (i.e.,
+ L32 or LP) DNS resource record while it is connected to the Internet.
+ An ILNPv4-capable multihomed host normally will have multiple Locator
+ values while multihomed. An IP host that is NOT ILNPv4-capable MUST
+ NOT have an L32 or LP record in its DNS entries. A node that is not
+ currently connected to the Internet might not have any L32 values in
+ the DNS associated with its owner name.
+
+ A DNS owner name that is naming a subnetwork, rather than naming a
+ host, MAY have an L32 record as a wild-card entry, thereby applying
+ to entries under that DNS owner name. This deployment scenario
+ probably is most common if the named subnetwork is, was, or might
+ become, mobile.
+
+ The type value for the L32 RR type is 105.
+
+ The L32 RR is class independent.
+
+ The L32 RR has no special TTL requirements.
+
+2.2.1. L32 RDATA Wire Format
+
+ The RDATA for an L32 RR consists of:
+
+ - a 16-bit Preference field
+ - a 32-bit Locator32 field
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preference | Locator32 (16 MSBs) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Locator32 (16 LSBs) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ MSB = most significant bit
+ LSB = least significant bit
+
+
+
+
+
+Atkinson, et al. Experimental [Page 8]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+2.2.1.1. The Preference Field
+
+ The <Preference> field is an unsigned 16-bit field in network byte
+ order that indicates the owner name's relative preference for this
+ L32 record among other L32 records associated with this owner name.
+ Lower Preference values are preferred over higher Preference values.
+
+2.2.1.2. The Locator32 Field
+
+ The <Locator32> field is an unsigned 32-bit integer in network byte
+ order that is identical on-the-wire to the ADDRESS field of the
+ existing DNS A record.
+
+2.2.2. L32 RR Presentation Format
+
+ The presentation of the format of the RDATA portion is as follows:
+
+ - The Preference field MUST be represented as a 16-bit unsigned
+ decimal integer.
+
+ - The Locator32 field MUST be represented using the same syntax used
+ for existing DNS A records (i.e., 4 decimal numbers separated by
+ periods without any embedded spaces).
+
+2.2.3. L32 RR Examples
+
+ An L32 record has the following logical components:
+
+ <owner-name> IN L32 <Preference> <Locator32>
+
+ In the above <owner-name> is the owner name string, <Preference> is
+ an unsigned 16-bit value, and <Locator32> is an unsigned 32-bit
+ value.
+
+ host1.example.com. IN L32 10 10.1.02.0
+ host1.example.com. IN L32 20 10.1.04.0
+ host2.example.com. IN L32 10 10.1.08.0
+
+ As L32 values have the same syntax and semantics as IPv4 routing
+ prefixes, when displayed for human readership, the values are
+ presented in the same dotted-decimal format as IPv4 addresses. An
+ example of this syntax is shown above.
+
+ In the example above, the owner name is from an FQDN for an
+ individual host. host1.example.com has two L32 values, so
+ host1.example.com is multihomed.
+
+
+
+
+
+Atkinson, et al. Experimental [Page 9]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+ Another example is when the owner name is that learned from an LP
+ record (see below for details of LP records).
+
+ l32-subnet1.example.com. IN L32 10 10.1.02.0
+ l32-subnet2.example.com. IN L32 20 10.1.04.0
+ l32-subnet3.example.com. IN L32 30 10.1.08.0
+
+ In this example above, the owner name is for a subnetwork rather than
+ an individual node.
+
+2.2.4. Additional Section Processing
+
+ To improve performance, ILNP-aware DNS servers and DNS resolvers MAY
+ attempt to return all NID, L64, and LP records for the same owner
+ name of the L32 RRset in the Additional section of the response, if
+ space permits.
+
+2.3. The L64 Resource Record
+
+ The L64 resource record (RR) is used to hold unsigned 64-bit Locator
+ values for ILNPv6-capable nodes.
+
+ L64 records are present only for ILNPv6-capable nodes. This
+ restriction is important; ILNP-capable nodes use the presence of L64
+ records in the DNS to learn that a correspondent node is also
+ ILNPv6-capable. While erroneous L64 records in the DNS for a node
+ that is not ILNP-capable would not prevent communication, such
+ erroneous DNS records could increase the delay at the start of an IP
+ session.
+
+ A given owner name might have zero or more L64 values at a given
+ time. An ILNPv6-capable host SHOULD have at least 1 Locator (i.e.,
+ L64 or LP) DNS resource record while it is connected to the Internet.
+ An ILNPv6-capable multihomed host normally will have multiple Locator
+ values while multihomed. An IP host that is NOT ILNPv6-capable MUST
+ NOT have an L64 or LP record in its DNS entries. A node that is not
+ currently connected to the Internet might not have any L64 values in
+ the DNS associated with its owner name.
+
+ A DNS owner name that is naming a subnetwork, rather than naming a
+ host, MAY have an L64 record as a wild-card entry, thereby applying
+ to entries under that DNS owner name. This deployment scenario
+ probably is most common if the named subnetwork is, was, or might
+ become, mobile.
+
+ The type value for the L64 RR type is 106.
+
+
+
+
+
+Atkinson, et al. Experimental [Page 10]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+ The L64 RR is class independent.
+
+ The L64 RR has no special TTL requirements.
+
+2.3.1. The L64 RDATA Wire Format
+
+ The RDATA for an L64 RR consists of:
+
+ - a 16-bit Preference field
+ - a 64-bit Locator64 field
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preference | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | Locator64 |
+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.3.1.1. The Preference Field
+
+ The <Preference> field is an unsigned 16-bit integer in network byte
+ order that indicates the owner name's relative preference for this
+ L64 record among other L64 records associated with this owner name.
+ Lower Preference values are preferred over higher Preference values.
+
+2.3.1.2. The Locator64 Field
+
+ The <Locator64> field is an unsigned 64-bit integer in network byte
+ order that has the same syntax and semantics as a 64-bit IPv6 routing
+ prefix.
+
+2.3.2. L64 RR Presentation Format
+
+ The presentation of the format of the RDATA portion is as follows:
+
+ - The Preference field MUST be represented as a 16-bit unsigned
+ decimal integer.
+
+ - The Locator64 field MUST be represented using the same syntax used
+ for AAAA records (i.e., groups of 4 hexadecimal digits separated by
+ colons). However, the 'compressed' display format (e.g., using
+ "::") that is specified in RFC 4291, Section 2.2 (2), MUST NOT be
+ used. This is done to avoid confusion with a 128-bit IPv6 address,
+ since the Locator64 is a 64-bit value, while the IPv6 address is a
+ 128-bit value.
+
+
+
+Atkinson, et al. Experimental [Page 11]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+2.3.3. L64 RR Examples
+
+ An L64 record has the following logical components:
+
+ <owner-name> IN L64 <Preference> <Locator64>
+
+ In the above, <owner-name> is the owner name string, <Preference> is
+ an unsigned 16-bit value, while <Locator64> is an unsigned 64-bit
+ value.
+
+ host1.example.com. IN L64 10 2001:0DB8:1140:1000
+ host1.example.com. IN L64 20 2001:0DB8:2140:2000
+ host2.example.com. IN L64 10 2001:0DB8:4140:4000
+
+ As L64 values have the same syntax and semantics as IPv6 routing
+ prefixes, when displayed for human readership, the values might
+ conveniently be presented in hexadecimal format, as above.
+
+ In the example above, the owner name is from an FQDN for an
+ individual host. host1.example.com has two L64 values, so it will be
+ multihomed.
+
+ Another example is when the owner name is that learned from an LP
+ record (see below for details of LP records).
+
+ l64-subnet1.example.com. IN L64 10 2001:0DB8:1140:1000
+ l64-subnet2.example.com. IN L64 20 2001:0DB8:2140:2000
+ l64-subnet3.example.com. IN L64 30 2001:0DB8:4140:4000
+
+ Here, the owner name is for a subnetwork rather than an individual
+ node.
+
+2.3.4. Additional Section Processing
+
+ To improve performance, ILNP-aware DNS servers and DNS resolvers MAY
+ attempt to return all NID, L32, and LP records for the same owner
+ name of the L64 RRset in the Additional section of the response, if
+ space permits.
+
+2.4. The LP Resource Record
+
+ The LP DNS resource record (RR) is used to hold the name of a
+ subnetwork for ILNP. The name is an FQDN which can then be used to
+ look up L32 or L64 records. LP is, effectively, a Locator Pointer to
+ L32 and/or L64 records.
+
+
+
+
+
+
+Atkinson, et al. Experimental [Page 12]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+ As described in [RFC6740], the LP RR provides one level of
+ indirection within the DNS in naming a Locator value. This is useful
+ in several deployment scenarios, such as for a multihomed site where
+ the multihoming is handled entirely by the site's border routers
+ (e.g., via Locator rewriting) or in some mobile network deployment
+ scenarios [RFC6748].
+
+ LP records MUST NOT be present for owner name values that are not
+ ILNP-capable nodes. This restriction is important; ILNP-capable
+ nodes use the presence of LP records in the DNS to infer that a
+ correspondent node is also ILNP-capable. While erroneous LP records
+ in the DNS for an owner name would not prevent communication,
+ presence of such erroneous DNS records could increase the delay at
+ the start of an IP session.
+
+ The type value for the LP RR type is 107.
+
+ The LP RR is class independent.
+
+ The LP RR has no special TTL requirements.
+
+2.4.1. LP RDATA Wire Format
+
+ The RDATA for an LP RR consists of:
+
+ - an unsigned 16-bit Preference field
+ - a variable-length FQDN field
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preference | /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
+ / /
+ / FQDN /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.4.1.1. The Preference Field
+
+ The <Preference> field contains an unsigned 16-bit integer in network
+ byte order that indicates the owner name's relative preference for
+ this LP record among other LP records associated with this owner
+ name. Lower Preference values are preferred over higher Preference
+ values.
+
+
+
+
+
+
+Atkinson, et al. Experimental [Page 13]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+2.4.1.2. The FQDN Field
+
+ The variable-length FQDN field contains the DNS target name that is
+ used to reference L32 and/or L64 records. This field MUST NOT have
+ the same value as the owner name of the LP RR instance.
+
+ A sender MUST NOT use DNS name compression on the FQDN field when
+ transmitting an LP RR.
+
+2.4.2. LP RR Presentation Format
+
+ The presentation of the format of the RDATA portion is as follows:
+
+ - The Preference field MUST be represented as a 16-bit unsigned
+ decimal integer.
+
+ - The FQDN field MUST be represented as a domain name.
+
+2.4.3. LP RR Examples
+
+ An LP record has the following logical components:
+
+ <owner-name> IN LP <Preference> <FQDN>
+
+ In the above, <owner-name> is the owner name string, <Preference> is
+ an unsigned 16-bit value, while <FQDN> is the domain name which
+ should be resolved further.
+
+ host1.example.com. IN LP 10 l64-subnet1.example.com.
+ host1.example.com. IN LP 10 l64-subnet2.example.com.
+ host1.example.com. IN LP 20 l32-subnet1.example.com.
+
+ In the example above, host1.example.com is multihomed on three
+ subnets. Resolving the FQDNs return in the LP records would allow
+ the actual subnet prefixes to be resolved, e.g., as in the examples
+ for the L32 and L64 RR descriptions, above. This level of
+ indirection allows the same L32 and/or L64 records to be used by many
+ hosts in the same subnetwork, easing management of the ILNP network
+ and potentially reducing the number of DNS Update transactions,
+ especially when that network is mobile [RAB09] or multihomed
+ [ABH09a].
+
+2.4.4. Additional Section Processing
+
+ To improve performance, ILNP-aware DNS servers and DNS resolvers MAY
+ attempt to return all L32 and L64 records for the same owner name of
+ the LP RRset in the Additional section of the response, if space
+ permits.
+
+
+
+Atkinson, et al. Experimental [Page 14]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+3. Deployment Example
+
+ Given a domain name, one can use the Domain Name System (DNS) to
+ discover the set of NID records, the set of L32 records, the set of
+ L64 records, and the set of LP records that are associated with that
+ DNS owner name.
+
+ For example:
+
+ host1.example.com. IN NID 10 0014:4fff:ff20:ee64
+ host1.example.com. IN L64 10 2001:0DB8:1140:1000
+
+ would be the minimum requirement for an ILNPv6 node that has owner
+ name host1.example.com and is connected to the Internet at the
+ subnetwork having routing prefix 2001:0DB8:1140:1000.
+
+ If that host were multihomed on two different IPv6 subnets:
+
+ host1.example.com. IN NID 10 0014:4fff:ff20:ee64
+ host1.example.com. IN L64 10 2001:0DB8:1140:1000
+ host1.example.com. IN L64 20 2001:0DB8:2140:2000
+
+ would indicate the Identifier and two subnets that host1.example.com
+ is attached to, along with the relative preference that a client
+ would use in selecting the Locator value for use in initiating
+ communication.
+
+ If host1.example.com were part of a mobile network, a DNS query might
+ return:
+
+ host1.example.com. IN NID 10 0014:4fff:ff20:ee64
+ host1.example.com. IN LP 10 mobile-net1.example.com.
+
+ and then a DNS query to find the current Locator value(s) for the
+ node named by the LP record:
+
+ mobile-net1.example.com. IN L64 2001:0DB8:8140:8000
+
+3.1. Use of ILNP Records
+
+ As these DNS records are only used with the Identifier-Locator
+ Network Protocol (ILNP), these records MUST NOT be present for a node
+ that does not support ILNP. This lookup process is considered to be
+ in the "forward" direction.
+
+ The Preference fields associated with the NID, L32, L64, and LP
+ records are used to indicate the owner name's preference for others
+ to use one particular NID, L32, L64, or LP record, rather than use
+
+
+
+Atkinson, et al. Experimental [Page 15]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+ another NID, L32, L64, or LP record also associated with that owner
+ name. Lower Preference field values are preferred over higher
+ Preference field values.
+
+ It is possible that a DNS stub resolver querying for one of these
+ record types will not receive all NID, L32, L64, and LP RR's in a
+ single response. Credible anecdotal reports indicate at least one
+ DNS recursive cache implementation actively drops all Additional Data
+ records that were not expected by that DNS recursive cache. So even
+ if the authoritative DNS server includes all the relevant records in
+ the Additional Data section of the DNS response, the querying DNS
+ stub resolver might not receive all of those Additional Data records.
+ DNS resolvers also might purge some ILNP RRsets before others, for
+ example, if NID RRsets have a longer DNS TTL value than Locator-
+ related (e.g., LP, L32, L64) RRsets. So a DNS stub resolver sending
+ queries to a DNS resolver cannot be certain if they have obtained all
+ available RRtypes for a given owner name. Therefore, the DNS stub
+ resolver SHOULD send follow-up DNS queries for RRTYPE values that
+ were missing and are desired, to ensure that the DNS stub resolver
+ receives all the necessary information.
+
+ Note nodes likely either to be mobile or to be multihomed normally
+ will have very low DNS TTL values for L32 and L64 records, as those
+ values might change frequently. However, the DNS TTL values for NID
+ and LP records normally will be higher, as those values are not
+ normally impacted by node location changes. Previous trace-driven
+ DNS simulations from MIT [JSBM02] and more recent experimental
+ validation of operational DNS from U. of St Andrews [BA11] both
+ indicate deployment and use of very short DNS TTL values within
+ 'stub' or 'leaf' DNS domains is not problematic.
+
+ An ILNP node MAY use any NID value associated with its DNS owner name
+ with any or all Locator (L32 or L64) values also associated with its
+ DNS owner name.
+
+ Existing DNS servers that do not explicitly support the new DNS RRs
+ defined in this specification are expected to follow existing
+ standards for handling unknown DNS RRs [RFC3597].
+
+3.2. Additional Section Processing
+
+ For all the records above, Additional Section Processing MAY be used.
+ This is intended to improve performance for both the DNS client and
+ the DNS server. For example, a node sending DNS query for an NID
+ owner name, such as host1.example.com, would benefit from receiving
+ all ILNP DNS records related to that owner name being returned, as it
+ is quite likely that the client will need that information to
+ initiate an ILNP session.
+
+
+
+Atkinson, et al. Experimental [Page 16]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+ However, this is not always the case: a DNS query for L64 for a
+ particular owner name might be made because the DNS TTL for a
+ previously resolved L64 RR has expired, while the NID RR for that
+ same owner name has a DNS TTL that has not expired.
+
+4. Security Considerations
+
+ These new DNS resource record types do not create any new
+ vulnerabilities in the Domain Name System.
+
+ Existing mechanisms for DNS Security can be used unchanged with these
+ record types [RFC4033] [RFC3007]. As of this writing, the DNS
+ Security mechanisms are believed to be widely implemented in
+ currently available DNS servers and DNS clients. Deployment of DNS
+ Security appears to be growing rapidly.
+
+ In situations where authentication of DNS data is a concern, the DNS
+ Security extensions SHOULD be used [RFC4033].
+
+ If these DNS records are updated dynamically over the network, then
+ the Secure Dynamic DNS Update [RFC3007] mechanism SHOULD be used to
+ secure such transactions.
+
+5. IANA Considerations
+
+ IANA has allocated each of the following DNS resource records
+ (described above in Section 2) a Data RRTYPE value according to the
+ procedures of Sections 3.1 and 3.1.1 of [RFC6195].
+
+ Type Value
+ ---- -----
+ NID 104
+ L32 105
+ L64 106
+ LP 107
+
+6. References
+
+6.1. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+Atkinson, et al. Experimental [Page 17]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+ [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
+ Update", RFC 3007, November 2000.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements", RFC
+ 4033, March 2005.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+ [RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA
+ Considerations", BCP 42, RFC 6195, March 2011.
+
+ [RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network
+ Protocol (ILNP) Architectural Description", RFC 6740,
+ November 2012.
+
+ [RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network
+ Protocol (ILNP) Engineering and Implementation
+ Considerations", RFC 6741, November 2012.
+
+6.2. Informative References
+
+ [ABH09a] Atkinson, R., Bhatti, S. and S. Hailes, "Site-Controlled
+ Secure Multi-Homing and Traffic Engineering For IP",
+ Proceedings of IEEE Military Communications Conference,
+ IEEE, Boston, MA, USA, October 2009.
+
+ [BA11] Bhatti, S. and R. Atkinson, "Reducing DNS Caching",
+ Proceedings of IEEE Global Internet Symposium (GI2011),
+ Shanghai, P.R. China. 15 April 2011.
+ <http://dx.doi.org/10.1109/INFCOMW.2011.5928919>
+
+ [JSBM02] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
+ performance and the effectiveness of caching", IEEE/ACM
+ Trans. Netw. 10(5) (October 2002), pp 589-603.
+ <http://dx.doi.org/10.1109/TNET.2002.803905>
+
+ [PHG02] Pappas, A., Hailes, S. and R. Giaffreda, "Mobile Host
+ Location Tracking through DNS", IEEE London
+ Communications Symposium, London, England, UK, September
+ 2002.
+ <http://www.ee.ucl.ac.uk/lcs/previous/LCS2002/LCS072.pdf>
+
+
+
+
+
+Atkinson, et al. Experimental [Page 18]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+ [RAB09] Rehunathan, D., Atkinson, R. and S. Bhatti, "Enabling
+ Mobile Networks Through Secure Naming", Proceedings of
+ IEEE Military Communications Conference (MILCOM), IEEE,
+ Boston, MA, USA, October 2009.
+
+ [SB00] Snoeren, A. and H. Balakrishnan, "An End-To-End Approach
+ To Host Mobility", Proceedings of 6th Conference on
+ Mobile Computing and Networking (MobiCom), ACM, Boston,
+ MA, USA, August 2000.
+
+ [SBK01] Snoeren, A., Balakrishnan, H., and M. Frans Kaashoek,
+ "Reconsidering Internet Mobility", Proceedings of 8th
+ Workshop on Hot Topics in Operating Systems (HotOS), IEEE
+ Computer Society, Elmau, Germany, May 2001.
+
+ [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
+ from the IAB Workshop on Routing and Addressing", RFC
+ 4984, September 2007.
+
+ [RFC6743] Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update
+ Message", RFC 6743, November 2012.
+
+ [RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination
+ Option for the Identifier-Locator Network Protocol for
+ IPv6 (ILNPv6)", RFC 6744, November 2012.
+
+ [RFC6745] Atkinson, R. and S. Bhatti, "ICMP Locator Update Message
+ for the Identifier-Locator Network Protocol for IPv4
+ (ILNPv4)", RFC 6745, November 2012.
+
+ [RFC6746] Atkinson, R. and S.Bhatti, "IPv4 Options for the
+ Identifier-Locator Network Protocol (ILNP)", RFC 6746,
+ November 2012.
+
+ [RFC6747] Atkinson, R. and S. Bhatti, "Address Resolution Protocol
+ (ARP) Extension for the Identifier-Locator Network
+ Protocol for IPv4 (ILNPv4)", RFC 6747, November 2012.
+
+ [RFC6748] Atkinson, R. and S. Bhatti, "Optional Advanced Deployment
+ Scenarios for the Identifier-Locator Network Protocol
+ (ILNP)", RFC 6748, November 2012.
+
+
+
+
+
+
+
+
+
+
+Atkinson, et al. Experimental [Page 19]
+\f
+RFC 6742 ILNP DNS November 2012
+
+
+7. Acknowledgements
+
+ Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa,
+ Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt,
+ Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson,
+ Robin Whittle, and John Wroclawski (in alphabetical order) provided
+ review and feedback on earlier versions of this document. Steve
+ Blake provided an especially thorough review of an early version of
+ the entire ILNP document set, which was extremely helpful. We also
+ wish to thank the anonymous reviewers of the various ILNP papers for
+ their feedback.
+
+ Roy Arends provided expert guidance on technical and procedural
+ aspects of DNS issues, for which the authors are greatly obliged.
+
+Authors' Addresses
+
+ RJ Atkinson
+ Consultant
+ San Jose, CA 95125
+ USA
+
+ EMail: rja.lists@gmail.com
+
+
+ SN Bhatti
+ School of Computer Science
+ University of St Andrews
+ North Haugh, St Andrews
+ Fife, Scotland
+ KY16 9SX, UK
+
+ EMail: saleem@cs.st-andrews.ac.uk
+
+
+ Scott Rose
+ US National Institute for Standards & Technology
+ 100 Bureau Drive
+ Gaithersburg, MD 20899
+ USA
+
+ EMail: scottr.nist@gmail.com
+
+
+
+
+
+
+
+
+
+Atkinson, et al. Experimental [Page 20]
+\f
unknown_totext(dns_rdata_t *rdata, dns_rdata_textctx_t *tctx,
isc_buffer_t *target);
+/*% INT16 Size */
+#define NS_INT16SZ 2
+/*% IPv6 Address Size */
+#define NS_LOCATORSZ 8
+
+/*%
+ * convert presentation level address to network order binary form.
+ * \return
+ * 1 if `src' is a valid [RFC1884 2.2] address, else 0.
+ * \note
+ * (1) does not touch `dst' unless it's returning 1.
+ */
+static inline int
+locator_pton(const char *src, unsigned char *dst) {
+ static const char xdigits_l[] = "0123456789abcdef",
+ xdigits_u[] = "0123456789ABCDEF";
+ unsigned char tmp[NS_LOCATORSZ];
+ unsigned char *tp = tmp, *endp;
+ const char *xdigits, *curtok;
+ int ch, seen_xdigits;
+ unsigned int val;
+
+ memset(tp, '\0', NS_LOCATORSZ);
+ endp = tp + NS_LOCATORSZ;
+ curtok = src;
+ seen_xdigits = 0;
+ val = 0;
+ while ((ch = *src++) != '\0') {
+ const char *pch;
+
+ pch = strchr((xdigits = xdigits_l), ch);
+ if (pch == NULL)
+ pch = strchr((xdigits = xdigits_u), ch);
+ if (pch != NULL) {
+ val <<= 4;
+ val |= (pch - xdigits);
+ if (++seen_xdigits > 4)
+ return (0);
+ continue;
+ }
+ if (ch == ':') {
+ curtok = src;
+ if (!seen_xdigits)
+ return (0);
+ if (tp + NS_INT16SZ > endp)
+ return (0);
+ *tp++ = (unsigned char) (val >> 8) & 0xff;
+ *tp++ = (unsigned char) val & 0xff;
+ seen_xdigits = 0;
+ val = 0;
+ continue;
+ }
+ return (0);
+ }
+ if (seen_xdigits) {
+ if (tp + NS_INT16SZ > endp)
+ return (0);
+ *tp++ = (unsigned char) (val >> 8) & 0xff;
+ *tp++ = (unsigned char) val & 0xff;
+ }
+ if (tp != endp)
+ return (0);
+ memcpy(dst, tmp, NS_LOCATORSZ);
+ return (1);
+}
+
static inline int
getquad(const void *src, struct in_addr *dst,
isc_lex_t *lexer, dns_rdatacallbacks_t *callbacks)
--- /dev/null
+/*
+ * Copyright (C) 2012 Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifndef RDATA_GENERIC_L32_105_C
+#define RDATA_GENERIC_L32_105_C
+
+#include <string.h>
+
+#include <isc/net.h>
+
+#define RRTYPE_L32_ATTRIBUTES (0)
+
+static inline isc_result_t
+fromtext_l32(ARGS_FROMTEXT) {
+ isc_token_t token;
+ struct in_addr addr;
+ isc_region_t region;
+
+ REQUIRE(type == 105);
+
+ UNUSED(type);
+ UNUSED(rdclass);
+ UNUSED(origin);
+ UNUSED(options);
+ UNUSED(callbacks);
+
+ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
+ ISC_FALSE));
+ if (token.value.as_ulong > 0xffffU)
+ RETTOK(ISC_R_RANGE);
+ RETERR(uint16_tobuffer(token.value.as_ulong, target));
+
+ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string,
+ ISC_FALSE));
+
+ if (getquad(DNS_AS_STR(token), &addr, lexer, callbacks) != 1)
+ RETTOK(DNS_R_BADDOTTEDQUAD);
+ isc_buffer_availableregion(target, ®ion);
+ if (region.length < 4)
+ return (ISC_R_NOSPACE);
+ memcpy(region.base, &addr, 4);
+ isc_buffer_add(target, 4);
+ return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+totext_l32(ARGS_TOTEXT) {
+ isc_region_t region;
+ char buf[sizeof("65000")];
+ unsigned short num;
+
+ REQUIRE(rdata->type == 105);
+ REQUIRE(rdata->length == 6);
+
+ UNUSED(tctx);
+
+ dns_rdata_toregion(rdata, ®ion);
+ num = uint16_fromregion(®ion);
+ isc_region_consume(®ion, 2);
+ sprintf(buf, "%u", num);
+ RETERR(str_totext(buf, target));
+
+ RETERR(str_totext(" ", target));
+
+ return (inet_totext(AF_INET, ®ion, target));
+}
+
+static inline isc_result_t
+fromwire_l32(ARGS_FROMWIRE) {
+ isc_region_t sregion;
+
+ REQUIRE(type == 105);
+
+ UNUSED(type);
+ UNUSED(options);
+ UNUSED(rdclass);
+ UNUSED(dctx);
+
+ isc_buffer_activeregion(source, &sregion);
+ if (sregion.length != 6)
+ return (DNS_R_FORMERR);
+ isc_buffer_forward(source, sregion.length);
+ return (mem_tobuffer(target, sregion.base, sregion.length));
+}
+
+static inline isc_result_t
+towire_l32(ARGS_TOWIRE) {
+
+ REQUIRE(rdata->type == 105);
+ REQUIRE(rdata->length == 6);
+
+ UNUSED(cctx);
+
+ return (mem_tobuffer(target, rdata->data, rdata->length));
+}
+
+static inline int
+compare_l32(ARGS_COMPARE) {
+ isc_region_t region1;
+ isc_region_t region2;
+
+ REQUIRE(rdata1->type == rdata2->type);
+ REQUIRE(rdata1->rdclass == rdata2->rdclass);
+ REQUIRE(rdata1->type == 105);
+ REQUIRE(rdata1->length == 6);
+ REQUIRE(rdata2->length == 6);
+
+ dns_rdata_toregion(rdata1, ®ion1);
+ dns_rdata_toregion(rdata2, ®ion2);
+ return (isc_region_compare(®ion1, ®ion2));
+}
+
+static inline isc_result_t
+fromstruct_l32(ARGS_FROMSTRUCT) {
+ dns_rdata_l32_t *l32 = source;
+ isc_uint32_t n;
+
+ REQUIRE(type == 105);
+ REQUIRE(source != NULL);
+ REQUIRE(l32->common.rdtype == type);
+ REQUIRE(l32->common.rdclass == rdclass);
+
+ UNUSED(type);
+ UNUSED(rdclass);
+
+ RETERR(uint16_tobuffer(l32->pref, target));
+ n = ntohl(l32->l32.s_addr);
+ return (uint32_tobuffer(n, target));
+}
+
+static inline isc_result_t
+tostruct_l32(ARGS_TOSTRUCT) {
+ isc_region_t region;
+ dns_rdata_l32_t *l32 = target;
+ isc_uint32_t n;
+
+ REQUIRE(rdata->type == 105);
+ REQUIRE(target != NULL);
+ REQUIRE(rdata->length == 6);
+
+ UNUSED(mctx);
+
+ l32->common.rdclass = rdata->rdclass;
+ l32->common.rdtype = rdata->type;
+ ISC_LINK_INIT(&l32->common, link);
+
+ dns_rdata_toregion(rdata, ®ion);
+ l32->pref = uint16_fromregion(®ion);
+ n = uint32_fromregion(®ion);
+ l32->l32.s_addr = htonl(n);
+ return (ISC_R_SUCCESS);
+}
+
+static inline void
+freestruct_l32(ARGS_FREESTRUCT) {
+ dns_rdata_l32_t *l32 = source;
+
+ REQUIRE(source != NULL);
+ REQUIRE(l32->common.rdtype == 105);
+
+ return;
+}
+
+static inline isc_result_t
+additionaldata_l32(ARGS_ADDLDATA) {
+
+ REQUIRE(rdata->type == 105);
+ REQUIRE(rdata->length == 6);
+
+ UNUSED(rdata);
+ UNUSED(add);
+ UNUSED(arg);
+
+ return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+digest_l32(ARGS_DIGEST) {
+ isc_region_t r;
+
+ REQUIRE(rdata->type == 105);
+ REQUIRE(rdata->length == 6);
+
+ dns_rdata_toregion(rdata, &r);
+
+ return ((digest)(arg, &r));
+}
+
+static inline isc_boolean_t
+checkowner_l32(ARGS_CHECKOWNER) {
+
+ REQUIRE(type == 105);
+
+ UNUSED(name);
+ UNUSED(type);
+ UNUSED(rdclass);
+ UNUSED(wildcard);
+
+ return (ISC_TRUE);
+}
+
+static inline isc_boolean_t
+checknames_l32(ARGS_CHECKNAMES) {
+
+ REQUIRE(rdata->type == 105);
+ REQUIRE(rdata->length == 6);
+
+ UNUSED(rdata);
+ UNUSED(owner);
+ UNUSED(bad);
+
+ return (ISC_TRUE);
+}
+
+static inline int
+casecompare_l32(ARGS_COMPARE) {
+ return (compare_l32(rdata1, rdata2));
+}
+
+#endif /* RDATA_GENERIC_L32_105_C */
--- /dev/null
+/*
+ * Copyright (C) 2012 Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/* */
+#ifndef GENERIC_L32_105_H
+#define GENERIC_L32_105_H 1
+
+typedef struct dns_rdata_l32 {
+ dns_rdatacommon_t common;
+ isc_uint16_t pref;
+ struct in_addr l32;
+} dns_rdata_l32_t;
+
+#endif /* GENERIC_L32_105_H */
--- /dev/null
+/*
+ * Copyright (C) 2012 Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifndef RDATA_GENERIC_L64_106_C
+#define RDATA_GENERIC_L64_106_C
+
+#include <string.h>
+
+#include <isc/net.h>
+
+#define RRTYPE_L64_ATTRIBUTES (0)
+
+static inline isc_result_t
+fromtext_l64(ARGS_FROMTEXT) {
+ isc_token_t token;
+ unsigned char locator[NS_LOCATORSZ];
+
+ REQUIRE(type == 106);
+
+ UNUSED(type);
+ UNUSED(rdclass);
+ UNUSED(origin);
+ UNUSED(options);
+ UNUSED(callbacks);
+
+ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
+ ISC_FALSE));
+ if (token.value.as_ulong > 0xffffU)
+ RETTOK(ISC_R_RANGE);
+ RETERR(uint16_tobuffer(token.value.as_ulong, target));
+
+ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string,
+ ISC_FALSE));
+
+ if (locator_pton(DNS_AS_STR(token), locator) != 1)
+ RETTOK(DNS_R_SYNTAX);
+ return (mem_tobuffer(target, locator, NS_LOCATORSZ));
+}
+
+static inline isc_result_t
+totext_l64(ARGS_TOTEXT) {
+ isc_region_t region;
+ char buf[sizeof("xxxx:xxxx:xxxx:xxxx")];
+ unsigned short num;
+
+ REQUIRE(rdata->type == 106);
+ REQUIRE(rdata->length == 10);
+
+ UNUSED(tctx);
+
+ dns_rdata_toregion(rdata, ®ion);
+ num = uint16_fromregion(®ion);
+ isc_region_consume(®ion, 2);
+ sprintf(buf, "%u", num);
+ RETERR(str_totext(buf, target));
+
+ RETERR(str_totext(" ", target));
+
+ sprintf(buf, "%x:%x:%x:%x",
+ region.base[0]<<8 | region.base[1],
+ region.base[2]<<8 | region.base[3],
+ region.base[4]<<8 | region.base[5],
+ region.base[6]<<8 | region.base[7]);
+ return (str_totext(buf, target));
+}
+
+static inline isc_result_t
+fromwire_l64(ARGS_FROMWIRE) {
+ isc_region_t sregion;
+
+ REQUIRE(type == 106);
+
+ UNUSED(type);
+ UNUSED(options);
+ UNUSED(rdclass);
+ UNUSED(dctx);
+
+ isc_buffer_activeregion(source, &sregion);
+ if (sregion.length != 10)
+ return (DNS_R_FORMERR);
+ isc_buffer_forward(source, sregion.length);
+ return (mem_tobuffer(target, sregion.base, sregion.length));
+}
+
+static inline isc_result_t
+towire_l64(ARGS_TOWIRE) {
+
+ REQUIRE(rdata->type == 106);
+ REQUIRE(rdata->length == 10);
+
+ UNUSED(cctx);
+
+ return (mem_tobuffer(target, rdata->data, rdata->length));
+}
+
+static inline int
+compare_l64(ARGS_COMPARE) {
+ isc_region_t region1;
+ isc_region_t region2;
+
+ REQUIRE(rdata1->type == rdata2->type);
+ REQUIRE(rdata1->rdclass == rdata2->rdclass);
+ REQUIRE(rdata1->type == 106);
+ REQUIRE(rdata1->length == 10);
+ REQUIRE(rdata2->length == 10);
+
+ dns_rdata_toregion(rdata1, ®ion1);
+ dns_rdata_toregion(rdata2, ®ion2);
+ return (isc_region_compare(®ion1, ®ion2));
+}
+
+static inline isc_result_t
+fromstruct_l64(ARGS_FROMSTRUCT) {
+ dns_rdata_l64_t *l64 = source;
+
+ REQUIRE(type == 106);
+ REQUIRE(source != NULL);
+ REQUIRE(l64->common.rdtype == type);
+ REQUIRE(l64->common.rdclass == rdclass);
+
+ UNUSED(type);
+ UNUSED(rdclass);
+
+ RETERR(uint16_tobuffer(l64->pref, target));
+ return (mem_tobuffer(target, l64->l64, sizeof(l64->l64)));
+}
+
+static inline isc_result_t
+tostruct_l64(ARGS_TOSTRUCT) {
+ isc_region_t region;
+ dns_rdata_l64_t *l64 = target;
+
+ REQUIRE(rdata->type == 106);
+ REQUIRE(target != NULL);
+ REQUIRE(rdata->length == 10);
+
+ UNUSED(mctx);
+
+ l64->common.rdclass = rdata->rdclass;
+ l64->common.rdtype = rdata->type;
+ ISC_LINK_INIT(&l64->common, link);
+
+ dns_rdata_toregion(rdata, ®ion);
+ l64->pref = uint16_fromregion(®ion);
+ memcpy(l64->l64, region.base, region.length);
+ return (ISC_R_SUCCESS);
+}
+
+static inline void
+freestruct_l64(ARGS_FREESTRUCT) {
+ dns_rdata_l64_t *l64 = source;
+
+ REQUIRE(source != NULL);
+ REQUIRE(l64->common.rdtype == 106);
+
+ return;
+}
+
+static inline isc_result_t
+additionaldata_l64(ARGS_ADDLDATA) {
+
+ REQUIRE(rdata->type == 106);
+ REQUIRE(rdata->length == 10);
+
+ UNUSED(rdata);
+ UNUSED(add);
+ UNUSED(arg);
+
+ return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+digest_l64(ARGS_DIGEST) {
+ isc_region_t r;
+
+ REQUIRE(rdata->type == 106);
+ REQUIRE(rdata->length == 10);
+
+ dns_rdata_toregion(rdata, &r);
+
+ return ((digest)(arg, &r));
+}
+
+static inline isc_boolean_t
+checkowner_l64(ARGS_CHECKOWNER) {
+
+ REQUIRE(type == 106);
+
+ UNUSED(name);
+ UNUSED(type);
+ UNUSED(rdclass);
+ UNUSED(wildcard);
+
+ return (ISC_TRUE);
+}
+
+static inline isc_boolean_t
+checknames_l64(ARGS_CHECKNAMES) {
+
+ REQUIRE(rdata->type == 106);
+ REQUIRE(rdata->length == 10);
+
+ UNUSED(rdata);
+ UNUSED(owner);
+ UNUSED(bad);
+
+ return (ISC_TRUE);
+}
+
+static inline int
+casecompare_l64(ARGS_COMPARE) {
+ return (compare_l64(rdata1, rdata2));
+}
+
+#endif /* RDATA_GENERIC_L64_106_C */
--- /dev/null
+/*
+ * Copyright (C) 2012 Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/* */
+#ifndef GENERIC_L64_106_H
+#define GENERIC_L64_106_H 1
+
+typedef struct dns_rdata_l64 {
+ dns_rdatacommon_t common;
+ isc_uint16_t pref;
+ unsigned char l64[8];
+} dns_rdata_l64_t;
+
+#endif /* GENERIC_L64_106_H */
--- /dev/null
+/*
+ * Copyright (C) 2004, 2005, 2007, 2009 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 1998-2001, 2003 Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifndef RDATA_GENERIC_LP_107_C
+#define RDATA_GENERIC_LP_107_C
+
+#include <string.h>
+
+#include <isc/net.h>
+
+#define RRTYPE_LP_ATTRIBUTES (0)
+
+static inline isc_result_t
+fromtext_lp(ARGS_FROMTEXT) {
+ isc_token_t token;
+ dns_name_t name;
+ isc_buffer_t buffer;
+
+ REQUIRE(type == 107);
+
+ UNUSED(type);
+ UNUSED(rdclass);
+ UNUSED(callbacks);
+
+ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
+ ISC_FALSE));
+ if (token.value.as_ulong > 0xffffU)
+ RETTOK(ISC_R_RANGE);
+ RETERR(uint16_tobuffer(token.value.as_ulong, target));
+
+ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string,
+ ISC_FALSE));
+
+ dns_name_init(&name, NULL);
+ buffer_fromregion(&buffer, &token.value.as_region);
+ origin = (origin != NULL) ? origin : dns_rootname;
+ return (dns_name_fromtext(&name, &buffer, origin, options, target));
+}
+
+static inline isc_result_t
+totext_lp(ARGS_TOTEXT) {
+ isc_region_t region;
+ dns_name_t name;
+ dns_name_t prefix;
+ isc_boolean_t sub;
+ char buf[sizeof("64000")];
+ unsigned short num;
+
+ REQUIRE(rdata->type == 107);
+ REQUIRE(rdata->length != 0);
+
+ dns_name_init(&name, NULL);
+ dns_name_init(&prefix, NULL);
+
+ dns_rdata_toregion(rdata, ®ion);
+ num = uint16_fromregion(®ion);
+ isc_region_consume(®ion, 2);
+ sprintf(buf, "%u", num);
+ RETERR(str_totext(buf, target));
+
+ RETERR(str_totext(" ", target));
+
+ dns_name_fromregion(&name, ®ion);
+ sub = name_prefix(&name, tctx->origin, &prefix);
+ return (dns_name_totext(&prefix, sub, target));
+}
+
+static inline isc_result_t
+fromwire_lp(ARGS_FROMWIRE) {
+ dns_name_t name;
+ isc_region_t sregion;
+
+ REQUIRE(type == 107);
+
+ UNUSED(type);
+ UNUSED(rdclass);
+
+ dns_decompress_setmethods(dctx, DNS_COMPRESS_GLOBAL14);
+
+ dns_name_init(&name, NULL);
+
+ isc_buffer_activeregion(source, &sregion);
+ if (sregion.length < 2)
+ return (ISC_R_UNEXPECTEDEND);
+ RETERR(mem_tobuffer(target, sregion.base, 2));
+ isc_buffer_forward(source, 2);
+ return (dns_name_fromwire(&name, source, dctx, options, target));
+}
+
+static inline isc_result_t
+towire_lp(ARGS_TOWIRE) {
+
+ REQUIRE(rdata->type == 107);
+ REQUIRE(rdata->length != 0);
+
+ UNUSED(cctx);
+
+ return (mem_tobuffer(target, rdata->data, rdata->length));
+}
+
+static inline int
+compare_lp(ARGS_COMPARE) {
+ isc_region_t region1;
+ isc_region_t region2;
+
+ REQUIRE(rdata1->type == rdata2->type);
+ REQUIRE(rdata1->rdclass == rdata2->rdclass);
+ REQUIRE(rdata1->type == 107);
+ REQUIRE(rdata1->length != 0);
+ REQUIRE(rdata2->length != 0);
+
+ dns_rdata_toregion(rdata1, ®ion1);
+ dns_rdata_toregion(rdata2, ®ion2);
+
+ return (isc_region_compare(®ion1, ®ion2));
+}
+
+static inline isc_result_t
+fromstruct_lp(ARGS_FROMSTRUCT) {
+ dns_rdata_lp_t *lp = source;
+ isc_region_t region;
+
+ REQUIRE(type == 107);
+ REQUIRE(source != NULL);
+ REQUIRE(lp->common.rdtype == type);
+ REQUIRE(lp->common.rdclass == rdclass);
+
+ UNUSED(type);
+ UNUSED(rdclass);
+
+ RETERR(uint16_tobuffer(lp->pref, target));
+ dns_name_toregion(&lp->lp, ®ion);
+ return (isc_buffer_copyregion(target, ®ion));
+}
+
+static inline isc_result_t
+tostruct_lp(ARGS_TOSTRUCT) {
+ isc_region_t region;
+ dns_rdata_lp_t *lp = target;
+ dns_name_t name;
+
+ REQUIRE(rdata->type == 107);
+ REQUIRE(target != NULL);
+ REQUIRE(rdata->length != 0);
+
+ lp->common.rdclass = rdata->rdclass;
+ lp->common.rdtype = rdata->type;
+ ISC_LINK_INIT(&lp->common, link);
+
+ dns_name_init(&name, NULL);
+ dns_rdata_toregion(rdata, ®ion);
+ lp->pref = uint16_fromregion(®ion);
+ isc_region_consume(®ion, 2);
+ dns_name_fromregion(&name, ®ion);
+ dns_name_init(&lp->lp, NULL);
+ RETERR(name_duporclone(&name, mctx, &lp->lp));
+ lp->mctx = mctx;
+ return (ISC_R_SUCCESS);
+}
+
+static inline void
+freestruct_lp(ARGS_FREESTRUCT) {
+ dns_rdata_lp_t *lp = source;
+
+ REQUIRE(source != NULL);
+ REQUIRE(lp->common.rdtype == 107);
+
+ if (lp->mctx == NULL)
+ return;
+
+ dns_name_free(&lp->lp, lp->mctx);
+ lp->mctx = NULL;
+}
+
+static inline isc_result_t
+additionaldata_lp(ARGS_ADDLDATA) {
+ dns_name_t name;
+ dns_offsets_t offsets;
+ isc_region_t region;
+ isc_result_t result;
+
+ REQUIRE(rdata->type == 107);
+
+ dns_name_init(&name, offsets);
+ dns_rdata_toregion(rdata, ®ion);
+ isc_region_consume(®ion, 2);
+ dns_name_fromregion(&name, ®ion);
+
+ result = (add)(arg, &name, dns_rdatatype_l32);
+ if (result != ISC_R_SUCCESS)
+ return (result);
+ return ((add)(arg, &name, dns_rdatatype_l64));
+}
+
+static inline isc_result_t
+digest_lp(ARGS_DIGEST) {
+ isc_region_t region;
+
+ REQUIRE(rdata->type == 107);
+
+ dns_rdata_toregion(rdata, ®ion);
+ return ((digest)(arg, ®ion));
+}
+
+static inline isc_boolean_t
+checkowner_lp(ARGS_CHECKOWNER) {
+
+ REQUIRE(type == 107);
+
+ UNUSED(type);
+ UNUSED(rdclass);
+ UNUSED(name);
+ UNUSED(wildcard);
+
+ return (ISC_TRUE);
+}
+
+static inline isc_boolean_t
+checknames_lp(ARGS_CHECKNAMES) {
+
+ REQUIRE(rdata->type == 107);
+
+ UNUSED(bad);
+ UNUSED(owner);
+
+ return (ISC_TRUE);
+}
+
+static inline int
+casecompare_lp(ARGS_COMPARE) {
+ dns_name_t name1;
+ dns_name_t name2;
+ isc_region_t region1;
+ isc_region_t region2;
+ int order;
+
+ REQUIRE(rdata1->type == rdata2->type);
+ REQUIRE(rdata1->rdclass == rdata2->rdclass);
+ REQUIRE(rdata1->type == 107);
+ REQUIRE(rdata1->length != 0);
+ REQUIRE(rdata2->length != 0);
+
+ order = memcmp(rdata1->data, rdata2->data, 2);
+ if (order != 0)
+ return (order < 0 ? -1 : 1);
+
+ dns_name_init(&name1, NULL);
+ dns_name_init(&name2, NULL);
+
+ dns_rdata_toregion(rdata1, ®ion1);
+ dns_rdata_toregion(rdata2, ®ion2);
+
+ isc_region_consume(®ion1, 2);
+ isc_region_consume(®ion2, 2);
+
+ dns_name_fromregion(&name1, ®ion1);
+ dns_name_fromregion(&name2, ®ion2);
+
+ return (dns_name_rdatacompare(&name1, &name2));
+}
+
+#endif /* RDATA_GENERIC_LP_107_C */
--- /dev/null
+/*
+ * Copyright (C) 2012 Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/* */
+#ifndef GENERIC_LP_107_H
+#define GENERIC_LP_107_H 1
+
+typedef struct dns_rdata_lp {
+ dns_rdatacommon_t common;
+ isc_mem_t *mctx;
+ isc_uint16_t pref;
+ dns_name_t lp;
+} dns_rdata_lp_t;
+
+#endif /* GENERIC_LP_107_H */
--- /dev/null
+/*
+ * Copyright (C) 2012 Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifndef RDATA_GENERIC_NID_104_C
+#define RDATA_GENERIC_NID_104_C
+
+#include <string.h>
+
+#include <isc/net.h>
+
+#define RRTYPE_NID_ATTRIBUTES (0)
+
+static inline isc_result_t
+fromtext_nid(ARGS_FROMTEXT) {
+ isc_token_t token;
+ unsigned char locator[NS_LOCATORSZ];
+
+ REQUIRE(type == 104);
+
+ UNUSED(type);
+ UNUSED(rdclass);
+ UNUSED(origin);
+ UNUSED(options);
+ UNUSED(callbacks);
+
+ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
+ ISC_FALSE));
+ if (token.value.as_ulong > 0xffffU)
+ RETTOK(ISC_R_RANGE);
+ RETERR(uint16_tobuffer(token.value.as_ulong, target));
+
+ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string,
+ ISC_FALSE));
+
+ if (locator_pton(DNS_AS_STR(token), locator) != 1)
+ RETTOK(DNS_R_SYNTAX);
+ return (mem_tobuffer(target, locator, NS_LOCATORSZ));
+}
+
+static inline isc_result_t
+totext_nid(ARGS_TOTEXT) {
+ isc_region_t region;
+ char buf[sizeof("xxxx:xxxx:xxxx:xxxx")];
+ unsigned short num;
+
+ REQUIRE(rdata->type == 104);
+ REQUIRE(rdata->length != 0);
+
+ UNUSED(tctx);
+
+ dns_rdata_toregion(rdata, ®ion);
+ num = uint16_fromregion(®ion);
+ isc_region_consume(®ion, 2);
+ sprintf(buf, "%u", num);
+ RETERR(str_totext(buf, target));
+
+ RETERR(str_totext(" ", target));
+
+ sprintf(buf, "%x:%x:%x:%x",
+ region.base[0]<<8 | region.base[1],
+ region.base[2]<<8 | region.base[3],
+ region.base[4]<<8 | region.base[5],
+ region.base[6]<<8 | region.base[7]);
+ return (str_totext(buf, target));
+}
+
+static inline isc_result_t
+fromwire_nid(ARGS_FROMWIRE) {
+ isc_region_t sregion;
+
+ REQUIRE(type == 104);
+
+ UNUSED(type);
+ UNUSED(options);
+ UNUSED(rdclass);
+ UNUSED(dctx);
+
+ isc_buffer_activeregion(source, &sregion);
+ if (sregion.length != 10)
+ return (DNS_R_FORMERR);
+ isc_buffer_forward(source, sregion.length);
+ return (mem_tobuffer(target, sregion.base, sregion.length));
+}
+
+static inline isc_result_t
+towire_nid(ARGS_TOWIRE) {
+
+ REQUIRE(rdata->type == 104);
+ REQUIRE(rdata->length == 10);
+
+ UNUSED(cctx);
+
+ return (mem_tobuffer(target, rdata->data, rdata->length));
+}
+
+static inline int
+compare_nid(ARGS_COMPARE) {
+ isc_region_t region1;
+ isc_region_t region2;
+
+ REQUIRE(rdata1->type == rdata2->type);
+ REQUIRE(rdata1->rdclass == rdata2->rdclass);
+ REQUIRE(rdata1->type == 104);
+ REQUIRE(rdata1->length == 10);
+ REQUIRE(rdata2->length == 10);
+
+ dns_rdata_toregion(rdata1, ®ion1);
+ dns_rdata_toregion(rdata2, ®ion2);
+ return (isc_region_compare(®ion1, ®ion2));
+}
+
+static inline isc_result_t
+fromstruct_nid(ARGS_FROMSTRUCT) {
+ dns_rdata_nid_t *nid = source;
+
+ REQUIRE(type == 104);
+ REQUIRE(source != NULL);
+ REQUIRE(nid->common.rdtype == type);
+ REQUIRE(nid->common.rdclass == rdclass);
+
+ UNUSED(type);
+ UNUSED(rdclass);
+
+ RETERR(uint16_tobuffer(nid->pref, target));
+ return (mem_tobuffer(target, nid->nid, sizeof(nid->nid)));
+}
+
+static inline isc_result_t
+tostruct_nid(ARGS_TOSTRUCT) {
+ isc_region_t region;
+ dns_rdata_nid_t *nid = target;
+
+ REQUIRE(rdata->type == 104);
+ REQUIRE(target != NULL);
+ REQUIRE(rdata->length == 10);
+
+ UNUSED(mctx);
+
+ nid->common.rdclass = rdata->rdclass;
+ nid->common.rdtype = rdata->type;
+ ISC_LINK_INIT(&nid->common, link);
+
+ dns_rdata_toregion(rdata, ®ion);
+ nid->pref = uint16_fromregion(®ion);
+ memcpy(nid->nid, region.base, region.length);
+ return (ISC_R_SUCCESS);
+}
+
+static inline void
+freestruct_nid(ARGS_FREESTRUCT) {
+ dns_rdata_nid_t *nid = source;
+
+ REQUIRE(source != NULL);
+ REQUIRE(nid->common.rdtype == 104);
+
+ return;
+}
+
+static inline isc_result_t
+additionaldata_nid(ARGS_ADDLDATA) {
+
+ REQUIRE(rdata->type == 104);
+ REQUIRE(rdata->length == 10);
+
+ UNUSED(rdata);
+ UNUSED(add);
+ UNUSED(arg);
+
+ return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+digest_nid(ARGS_DIGEST) {
+ isc_region_t r;
+
+ REQUIRE(rdata->type == 104);
+ REQUIRE(rdata->length == 10);
+
+ dns_rdata_toregion(rdata, &r);
+
+ return ((digest)(arg, &r));
+}
+
+static inline isc_boolean_t
+checkowner_nid(ARGS_CHECKOWNER) {
+
+ REQUIRE(type == 104);
+
+ UNUSED(name);
+ UNUSED(type);
+ UNUSED(rdclass);
+ UNUSED(wildcard);
+
+ return (ISC_TRUE);
+}
+
+static inline isc_boolean_t
+checknames_nid(ARGS_CHECKNAMES) {
+
+ REQUIRE(rdata->type == 104);
+ REQUIRE(rdata->length == 10);
+
+ UNUSED(rdata);
+ UNUSED(owner);
+ UNUSED(bad);
+
+ return (ISC_TRUE);
+}
+
+static inline int
+casecompare_nid(ARGS_COMPARE) {
+ return (compare_nid(rdata1, rdata2));
+}
+
+#endif /* RDATA_GENERIC_NID_104_C */
--- /dev/null
+/*
+ * Copyright (C) 2012 Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/* */
+#ifndef GENERIC_NID_104_H
+#define GENERIC_NID_104_H 1
+
+typedef struct dns_rdata_nid {
+ dns_rdatacommon_t common;
+ isc_uint16_t pref;
+ unsigned char nid[8];
+} dns_rdata_nid_t;
+
+#endif /* GENERIC_NID_104_H */
projects / thirdparty / bind9.git / commitdiff
