RFC 6742
DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)
RFC 6742: DNS Resource Records for the Identifier-Locator Network Protocol (ILNP) 💖
Okay bestie, this one is RFC 6742 🎀, published in November 2012. It's an Experimental doc from the IRTF (Internet Research Task Force), and the authors are RJ Atkinson (Consultant), SN Bhatti (U. St Andrews) and S. Rose (US NIST). The ISSN is 2070-1721. It's a product of the IRTF Routing Research Group 🦋. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.
Abstract
Okay so this note adds some extra optional resource records to the Domain Name System (DNS) 🌸. They're for use with the Identifier-Locator Network Protocol (ILNP), and the whole doc came out of the IRTF Routing Research Group.
Status of This Memo
This doc is not an Internet Standards Track spec 🙈. It's published so people can look at it, try implementing it, and evaluate it.
It defines an Experimental Protocol for the Internet community 🧪. It's an IRTF product, and the IRTF shares the results of Internet-related research and development. Those results might not be ready for deployment, so keep that in mind 💀. This RFC is one or more members of the Routing Research Group's individual opinions, not an official group verdict. Docs the IRSG approves for publication aren't candidates for any level of Internet Standard. See Section 2 of RFC 5741 for the details.
If you want the current status, any errata, or a way to give feedback, check http://www.rfc-editor.org/info/rfc6742 🔗.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved ©️.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for 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 ...............................................201. Introduction ✨
This doc is part of the ILNP document set, and it got a LOT of review inside the IRTF Routing RG 👀. ILNP is one of the recommendations the RG Chairs made. Separately, various refereed research papers on ILNP have been published during this decade, so these ideas have had way more review than just the Routing RG 📚.
Real talk though, the views in this doc were considered controversial by the Routing RG. The RG still reached a consensus that it should be published 🤷♀️. The Routing RG has had remarkably little consensus on anything, so basically all Routing RG outputs are considered controversial 💀.
Right now, the Internet research and development community is exploring different ways to evolve the Internet Architecture. They're trying to solve a bunch of issues, including (but not only) the scalability of inter-domain routing [RFC4984] 📈. Other issues are also active concerns, like site multihoming, node multihoming, site/subnet mobility, and node mobility 🚀. There are several different classes of evolution being considered. One class is often called "Map and Encapsulate", where traffic gets mapped and then tunnelled through the inter-domain core of the Internet 🚇. Another class is sometimes known as "Identifier/Locator Split". This document is about a proposal in that second class 🧩.
ILNP was developed to explore a possible evolutionary direction for the Internet Architecture 🌱. You can find a description of the ILNP architecture in a separate document [RFC6740]. Most of the implementation and engineering details are isolated into a second document [RFC6741] 🛠️.
The Domain Name System (DNS) is the standard way Internet nodes look up information about addresses, mail exchangers, and other data about remote Internet nodes [RFC1034] [RFC1035] 🗺️.
More recently, the IETF defined standards-track security extensions to the DNS [RFC4033] 🔐. These can be used to authenticate signed DNS data records, and to store signed public keys in the DNS. The IETF also defined a standards-track approach for secure dynamic update of DNS records over the network [RFC3007] 🔄.
This document defines several new optional data resource records 💜. It specifies the syntax and the other items needed for independent implementations of these DNS resource records. The reader is assumed to know the basics of DNS, including [RFC1034] [RFC1035] 📖.
The idea of using DNS for rendezvous with mobile nodes or mobile networks has been proposed before, more than once, and independently, by several other researchers. For example, see [SB00], [SBK01], and [PHG02] 🫶.
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, you could imagine a "clean-slate" engineering design based on the ILNP architecture. In separate documents, the authors 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 🍓.
Lots of engineering aspects are common to both ILNPv4 and ILNPv6, and those are described in [RFC6741]. A full engineering spec for either ILNPv6 or ILNPv4 is beyond the scope of this document 🙅♀️.
If you want details that aren't covered here, go read these related ILNP docs:
- 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. An ILNP node uses it to tell its correspondent nodes about any changes to its set of valid Locators.
- d) [RFC6744] defines a new IPv6 Nonce Destination Option used by ILNPv6 nodes. It does two things: (1) it shows ILNP correspondent nodes (by being included in the initial packets of an ILNP session) that the node is running in ILNP mode, and (2) it prevents off-path attacks against ILNP ICMP messages. This Nonce is used, for example, with all ILNP ICMPv6 Locator Update messages exchanged among ILNP correspondent nodes 🔒.
- e) [RFC6745] defines a new ICMPv4 Locator Update message. An ILNP node uses it to tell its correspondent nodes about any changes to its set of valid Locators.
- f) [RFC6746] defines a new IPv4 Nonce Option, which ILNPv4 nodes use to carry a security nonce that prevents off-path attacks against ILNP ICMP messages. It also defines a new IPv4 Identifier Option used by ILNPv4 nodes 🪪.
- g) [RFC6747] describes extensions to the Address Resolution Protocol (ARP) for use with ILNPv4 🧭.
- h) [RFC6748] describes optional engineering and deployment functions for ILNP. These aren't required for ILNP to operate or be used, and they're provided as extra options 🎁.
1.2. Terminology 📝
In this document, the term "ILNP-aware" applies to a DNS component (either an authoritative server or a cache). It means the component tries to include other ILNP RRTypes in the Additional section of a DNS response. The point is to boost performance and cut down on follow-up queries for those other ILNP RRTypes ⚡. These other RRsets MAY be added to the Additional section if there's space, and only when the QTYPE equals NID, L64, L32, or LP. There's 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), which is called the "owner name" from here on. They're part of the work on the Identifier-Locator Network Protocol (ILNP) [RFC6740] 💖.
For clarity, throughout this section, the "RDATA" subsections specify the on-the-wire format for these records. The "Presentation Format" subsections specify the human-readable format used in a DNS configuration file (the "master file" defined by RFC 1035, Section 5.1) 📄.
2.1. The NID Resource Record 🪪
The Node Identifier (NID) DNS resource record (RR) holds 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 👑. Erroneous NID records in the DNS for a node that is not ILNP-capable wouldn't stop communication, but they could increase the delay at the start of an IP session 😬.
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 🎀
okay so the RDATA for an NID RR has just two parts, bestie 💖
- 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 is a 16-bit unsigned integer in network byte order 🔥 it tells you how much the owner name prefers this NID record compared to the other NID records attached to that same owner name ✨ lower Preference values win over higher ones, so the lowest number is the fave 👑
2.1.1.2. The NodeID Field 🦋
the NodeID field is an unsigned 64-bit value in network byte order 🌸 it follows the syntax rules for IPv6 interface identifiers [RFC4291], Section 2.5.1, but the semantics are a little different, and this is where it gets iconic 😭 IPv6 interface identifiers are tied to one specific interface on one specific node, but NodeID values are tied to one specific node, and they MAY be used with any interface of that node 🧚
2.1.2. NID RR Presentation Format 🌈
so this is how the RDATA portion gets written out when humans look at it 👀
- 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 these logical parts:
<owner-name> IN NID <Preference> <NodeID>so in that, <owner-name> is the owner name string, <Preference> is an unsigned 16-bit value, and <NodeID> is an unsigned 64-bit value 💜
here are some examples, periodt:
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:ee66NodeID values use the same syntax as IPv6 interface identifiers, so when they get displayed for humans, they show up in that same hexadecimal format 💖 you can see it in the example above ✨
2.1.4. Additional Section Processing 🫶
to make things faster, ILNP-aware DNS servers and DNS resolvers MAY try to return all L32, L64, and LP records for the same owner name as the NID RRset in the Additional section of the response, as long as there's space 🚀
2.2. The L32 Resource Record 🦋
an L32 DNS RR holds 32-bit Locator values for ILNPv4-capable nodes ✨
L32 records are only present for ILNPv4-capable nodes, and this rule matters a LOT 🔥 ILNP-capable nodes look for L32 records in the DNS to figure out whether a correspondent node is also ILNPv4-capable. Erroneous L32 records in the DNS for a node that isn't ILNP-capable wouldn't stop communication, but they could make the start of an IP session take longer 💀
a given owner name might have zero or more L32 values at any given time 🌸 an ILNPv4-capable host SHOULD have at least 1 Locator (i.e., L32 or LP) DNS resource record while it's connected to the Internet. an ILNPv4-capable multihomed host normally has multiple Locator values while it's multihomed 🧚 an IP host that is NOT ILNPv4-capable MUST NOT have an L32 or LP record in its DNS entries 🙅♀️ a node that isn't currently connected to the Internet might not have any L32 values in the DNS for its owner name 😴
a DNS owner name that names a subnetwork, rather than a host, MAY have an L32 record as a wild-card entry, which applies to entries under that owner name 🌈 this setup is probably most common when 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 has two parts:
- 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
2.2.1.1. The Preference Field 🌸
the <Preference> field is an unsigned 16-bit field in network byte order 💜 it shows how the owner name ranks this L32 record against the other L32 records tied to that owner name 🏆 lower Preference values are preferred over higher ones 👑
2.2.1.2. The Locator32 Field 🦋
the <Locator32> field is an unsigned 32-bit integer in network byte order, and it's identical on the wire to the ADDRESS field of the existing DNS A record 🫶
2.2.2. L32 RR Presentation Format 🎀
- 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 these logical parts:
<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.0L32 values have the same syntax and semantics as IPv4 routing prefixes, so when they're displayed for humans, they use the same dotted-decimal format as IPv4 addresses 🌈 you can see that in the example above 💖
in that example, the owner name is an FQDN for an individual host. host1.example.com has two L32 values, so host1.example.com is multihomed 🔥
another example is when the owner name is one learned from an LP record (more on LP records below) 🧚
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.0in this example, the owner name is for a subnetwork instead of an individual node 🚗
2.2.4. Additional Section Processing 🫶
to make things faster, ILNP-aware DNS servers and DNS resolvers MAY try to return all NID, L64, and LP records for the same owner name as the L32 RRset in the Additional section of the response, as long as there's space 🚀
2.3. The L64 Resource Record 🌸
the L64 resource record (RR) holds unsigned 64-bit Locator values for ILNPv6-capable nodes 💖
L64 records are only present for ILNPv6-capable nodes, and this restriction is super important 😭 ILNP-capable nodes check for L64 records in the DNS to learn that a correspondent node is also ILNPv6-capable. Erroneous L64 records in the DNS for a node that isn't ILNP-capable wouldn't prevent communication, but they 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's connected to the Internet. an ILNPv6-capable multihomed host normally has multiple Locator values while it's multihomed 🧚 an IP host that is NOT ILNPv6-capable MUST NOT have an L64 or LP record in its DNS entries 🙅♀️ a node that isn't currently connected to the Internet might not have any L64 values in the DNS for its owner name 😴
a DNS owner name that names a subnetwork, rather than a host, MAY have an L64 record as a wild-card entry, which applies to entries under that owner name 🎀 this setup is probably most common when the named subnetwork is, was, or might become, mobile 🚗
the type value for the L64 RR type is 106 ⭐
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 has two parts:
- 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 shows how the owner name ranks this L64 record against the other L64 records tied to that owner name 🏆 lower Preference values are preferred over higher ones ✨
2.3.1.2. The Locator64 Field 🌈
the <Locator64> field is an unsigned 64-bit integer in network byte order with the same syntax and semantics as a 64-bit IPv6 routing prefix 🦋
2.3.2. L64 RR Presentation Format 🫶
- 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. 🙈
2.3.3. L64 RR Examples
okay so an L64 record has these logical parts 🎀
<owner-name> IN L64 <Preference> <Locator64>the owner-name is the owner name string, the Preference is an unsigned 16-bit value, and the Locator64 is an unsigned 64-bit value. bestie, look at these examples 💖
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:4000L64 values have the same syntax and meaning as IPv6 routing prefixes, so when we show them to humans, we can display them in hexadecimal format, just like above. it's giving clean 💅
in the example above, the owner name is an FQDN for one individual host. host1.example.com has two L64 values, so it's multihomed 🦋
another example is when the owner name is one that was learned from an LP record (more on LP records below) 🌸
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:4000here the owner name is for a subnetwork instead of one individual node. main character energy for subnets 👑
2.3.4. Additional Section Processing
to make things faster, ILNP-aware DNS servers and DNS resolvers MAY try to return all NID, L32, and LP records for the same owner name as the L64 RRset in the Additional section of the response, if there's space 🧚
2.4. The LP Resource Record
the LP DNS resource record (RR) holds the name of a subnetwork for ILNP. that name is an FQDN, which you can then use to look up L32 or L64 records. basically, LP is a Locator Pointer to L32 and/or L64 records 🫶
as [RFC6740] explains, the LP RR gives you one level of indirection inside the DNS when naming a Locator value. this is super useful in a few setups, like a multihomed site where the multihoming is handled entirely by the site's border routers (for example, through Locator rewriting), or in some mobile network setups [RFC6748] 🌈
LP records MUST NOT be present for owner name values that are not ILNP-capable nodes. this one's important! ILNP-capable nodes use the presence of LP records in the DNS to figure out that a correspondent node is also ILNP-capable. wrong LP records wouldn't stop communication, but they could make the start of an IP session take longer 😭
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 has:
- 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 is an unsigned 16-bit integer in network byte order. it shows how the owner name ranks this LP record against the other LP records tied to the same owner name. lower Preference values win over higher ones 🎀
2.4.1.2. The FQDN Field
the variable-length FQDN field holds the DNS target name that's 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 sending an LP RR 💅
2.4.2. LP RR Presentation Format
here's how the RDATA part gets presented:
- 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 these logical parts:
<owner-name> IN LP <Preference> <FQDN>the owner-name is the owner name string, the Preference is an unsigned 16-bit value, and the FQDN is the domain name that 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 across three subnets 🌸 resolving the FQDNs returned in the LP records would let you find the actual subnet prefixes, like in the examples for the L32 and L64 RR descriptions above. this extra layer lets the same L32 and/or L64 records be used by lots of hosts in the same subnetwork. that makes managing the ILNP network way easier and can cut down on DNS Update transactions, especially when the network is mobile [RAB09] or multihomed [ABH09a] 🚀✨
2.4.4. Additional Section Processing
to make things faster, ILNP-aware DNS servers and DNS resolvers MAY try to return all L32 and L64 records for the same owner name as the LP RRset in the Additional section of the response, if there's space 💖
3. Deployment Example
with a domain name, you can use the Domain Name System (DNS) to find the set of NID records, the set of L32 records, the set of L64 records, and the set of LP records tied to 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:1000this would be the bare minimum for an ILNPv6 node with the owner name host1.example.com that's connected to the Internet at the subnetwork with routing prefix 2001:0DB8:1140:1000 🎀
if that host were multihomed across 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:2000then you'd get the Identifier plus both subnets host1.example.com is attached to, along with the relative preference a client would use when picking a Locator value to start communicating 👑
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 you'd send another 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:80003.1. Use of ILNP Records
these DNS records are only used with the Identifier-Locator Network Protocol (ILNP), so these records MUST NOT be present for a node that doesn't support ILNP 🚫 this lookup process counts as going in the "forward" direction.
the Preference fields on the NID, L32, L64, and LP records show the owner name's preference for others to use one particular NID, L32, L64, or LP record over another one tied to that same owner name. lower Preference field values win over higher ones 🏆
a DNS stub resolver asking for one of these record types might not get all of the NID, L32, L64, and LP RRs in a single response. there are credible anecdotal reports that at least one DNS recursive cache implementation drops all Additional Data records it didn't expect 😭 so even if the authoritative DNS server puts every relevant record in the Additional Data section of the response, the querying stub resolver might not get all of them. DNS resolvers might also purge some ILNP RRsets before others. for example, if NID RRsets have a longer DNS TTL than the Locator-related (e.g., LP, L32, L64) RRsets. so a DNS stub resolver sending queries to a DNS resolver can't be sure it has every available RRtype for a given owner name. therefore, the DNS stub resolver SHOULD send follow-up DNS queries for any RRTYPE values that were missing and are wanted, so it gets all the info it needs 🧠
nodes that are likely to be mobile or multihomed will usually have very low DNS TTL values for L32 and L64 records, since those values might change a lot. the DNS TTL values for NID and LP records will usually be higher, since location changes don't usually affect them 🌙 earlier trace-driven DNS simulations from MIT [JSBM02] and more recent experimental validation of operational DNS from U. of St Andrews [BA11] both show that using very short DNS TTL values inside 'stub' or 'leaf' DNS domains isn't a problem 🫶
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 don't 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
Additional Section Processing MAY be used for all the records above. it's meant to make things faster for both the DNS client and the DNS server. for example, a node sending a DNS query for an NID owner name, like host1.example.com, would benefit from getting back all the ILNP DNS records related to that owner name, since the client will very likely need that info to start an ILNP session 🚀
but it's not always like that! a DNS query for L64 for a particular owner name might happen because the DNS TTL for a previously resolved L64 RR has expired, even though the NID RR for that same owner name still has an unexpired DNS TTL ⏰
4. Security Considerations
okay this section is serious 😤 these new DNS resource record types do NOT create any new vulnerabilities in the Domain Name System. (no cap, that's the whole point 🛡️)
existing DNS Security mechanisms can be used unchanged with these record types [RFC4033] [RFC3007]. as of writing, the DNS Security mechanisms are believed to be widely implemented in currently available DNS servers and DNS clients. and deployment of DNS Security appears to be growing really fast 📈
where authentication of DNS data is a concern, the DNS Security extensions SHOULD be used [RFC4033] 🔐
if these DNS records get updated dynamically over the network, then the Secure Dynamic DNS Update [RFC3007] mechanism SHOULD be used to secure those transactions 🔒
5. IANA Considerations
IANA has given each of the following DNS resource records (described above in Section 2) a Data RRTYPE value, following the procedures in Sections 3.1 and 3.1.1 of [RFC6195] 🎀
Type Value
---- -----
NID 104
L32 105
L64 106
LP 1076. References
6. References ✨
6.1. Normative References 📚
okay bestie, these are the must-reads 💅 the stuff the spec leans on hard, so you need the whole reference list on hand 🫶
[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.
[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 🧠
these ones are the extra reading 🌸 the background, the papers, and the rest of the ILNP family, all listed so you can go deep whenever you're feeling like a nerd 🤓✨
[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>
[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.7. Acknowledgements 💖
huge thank-yous time 🥹 these people reviewed earlier versions of the document and gave feedback, and they're listed in alphabetical order: 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 👑
Steve Blake gave an especially thorough review of an early version of the entire ILNP document set, which was extremely helpful 🙌 the authors also want to thank the anonymous reviewers of the various ILNP papers for their feedback 🦋
Roy Arends gave expert guidance on the technical and procedural side of DNS issues, and 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📦 where this page comes from
- ietf: rfc6742 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms