RFC 5505

Principles of Internet Host Configuration

📅 published May 2009, from ietf

RFC 5505: Principles of Internet Host Configuration 💖

okay so bestie, this is the title block 🎀 It's from the Network Working Group, and the document is RFC 5505, titled Principles of Internet Host Configuration. The authors are B. Aboba, D. Thaler, L. Andersson, and S. Cheshire, and it was written under the Internet Architecture Board. It's dated May 2009 and its category is Informational 🧚 The title block doesn't have any Obsoletes or Updates line, so this doc doesn't list anything it replaces or changes.

Status of This Memo ✨

This memo gives information to the Internet community. It is NOT a spec for any kind of Internet standard 🙈 Distribution of this memo is unlimited 💅

Copyright (c) 2009 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, as they were in effect on the date this document was published. The link is http://trustee.ietf.org/license-info. Please read these carefully, because they spell out your rights and restrictions for this doc 📜

Abstract 🌸

So the big idea is that this document describes principles of Internet host configuration 🍓 It covers configuration of Internet-layer parameters, plus parameters that affect higher-layer protocols. It's giving full-stack 😭

Table of Contents 🧚

1. Introduction ....................................................3
   1.1. Terminology ................................................3
   1.2. Internet Host Configuration ................................4
        1.2.1. Internet-Layer Configuration ........................4
        1.2.2. Higher-Layer Configuration ..........................6
2. Principles ......................................................7
   2.1. Minimize Configuration .....................................7
   2.2. Less Is More ...............................................7
   2.3. Minimize Diversity .........................................8
   2.4. Lower-Layer Independence ...................................9
   2.5. Configuration Is Not Access Control .......................11
3. Additional Discussion ..........................................12
   3.1. Reliance on General-Purpose Mechanisms ....................12
   3.2. Relationship between IP Configuration and Service
        Discovery .................................................13
        3.2.1. Fate Sharing .......................................14
   3.3. Discovering Names versus Addresses ........................15
   3.4. Dual-Stack Issues .........................................15
   3.5. Relationship between Per-Interface and Per-Host
        Configuration .............................................16
4. Security Considerations ........................................17
   4.1. Configuration Authentication ..............................18
5. Informative References .........................................19
Appendix A. Acknowledgments .......................................24
Appendix B. IAB Members at the Time of This Writing ...............24

1. Introduction ✨

This doc describes principles of Internet host [STD3] configuration 🎀 It covers configuration of Internet-layer parameters, plus parameters that affect higher-layer protocols.

In recent years a bunch of architectural questions have popped up, so the doc gives guidance to protocol developers on these:

  • Which protocol layers and general approaches are best for configuring different parameters.
  • How parameter configuration relates to service discovery.
  • How per-interface configuration relates to per-host configuration.
  • How network access authentication relates to host configuration.
  • Whether it's desirable to support self-configuration of parameters, or to skip parameter configuration altogether.
  • What role link-layer protocols and tunneling protocols play in Internet host configuration.

The link-layer and tunneling protocols are a big deal 🔥 They can change the properties of a link as higher layers see it. For example, whether privacy extensions [RFC4941] are available to applications depends on them 👑

1.1. Terminology 🦋

link

A communication facility or medium that nodes can use to talk at the link layer, which is the layer right below IP. Examples are Ethernets (simple or bridged), Point-to-Point Protocol (PPP) links, X.25, Frame Relay, or ATM networks. Internet- or higher-layer "tunnels" count too, like tunnels over IPv4 or IPv6 itself 🌈

on link

An address assigned to an interface on a specified link 💜

off link

The opposite of "on link." It's an address that isn't assigned to any interface on the specified link 🙈

mobility agent

Either a home agent or a foreign agent [RFC3344] [RFC3775] 🧚

1.2. Internet Host Configuration 💖

1.2.1. Internet-Layer Configuration 🌸

Internet-layer configuration is the configuration needed to keep the Internet layer running. It includes per-interface and per-host parameters, like IP address(es), subnet prefix(es), default gateway(s), mobility agent(s), boot service configuration, and other parameters 🍓

IP address(es)

Internet Protocol (IP) address configuration covers both link-scope addresses and global addresses. It's a vital step, because basically all of IP networking assumes that hosts have IP address(es) tied to each of their active network interface(s) ✨ When an IP address is used as the source address of a packet, it tells you who sent it. When it's the destination address of a unicast packet, it tells you who the intended receiver is 💅

The only common example of IP-based protocols running without an IP address is address configuration, like using DHCPv4 [RFC2131] to get an address. In that case DHCPv4 is running before the host has an IPv4 address, so the DHCP protocol designers had two choices: use IP without an IP address, or don't use IP at all. They picked IP without an address. Making IPv4 self-reliant, so it configures itself using its own IPv4 packets instead of depending on another protocol, was worth the drawbacks of running in that constrained mode 🎀 Any use of IP for things other than address configuration can safely assume the host will have one or more IP addresses. Those might be self-configured link-local addresses [RFC3927] [RFC4862], or addresses set up through DHCP or other means 🫶

Subnet prefix(es)

Once a subnet prefix is configured on an interface, hosts with an IP address can send unicast IP packets directly to on-link hosts in the same subnet prefix 🦋

Default gateway(s)

Once a default gateway is configured on an interface, hosts with an IP address can send unicast IP packets to that gateway so it can forward them to off-link hosts 🌈

Mobility agent(s)

Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] each have their own ways of finding home agents. But mobile nodes can also use dynamic home agent configuration, which is lowkey iconic 👑

Boot service configuration

Boot service configuration is the configuration a host needs to get and maybe also verify an appropriate boot image 💜 This is for disk-less hosts that want a boot image through things like the Trivial File Transfer Protocol (TFTP) [RFC1350], Network File System (NFS) [RFC3530], and Internet Small Computer Systems Interface (iSCSI) [RFC3720] [RFC4173]. It can also help when you need to update the boot image of a host that has a disk, like in the Preboot Execution Environment [PXE] [RFC4578] 🧚 Strictly speaking, boot services run above the Internet layer, since boot service is used to get the Internet-layer code. But it can still count as part of Internet-layer configuration. Boot service parameters can be given per interface, but loading and verifying a boot image changes how the whole host behaves 🔥

Other IP parameters

Internet-layer configuration also covers per-host parameters (for example, hostname) and per-interface parameters (for example, the IP Time-To-Live (TTL) used in outgoing packets, turning IP forwarding and source routing on or off, and the Maximum Transmission Unit (MTU)) 🍓

1.2.2. Higher-Layer Configuration 🦋

Higher-layer configuration is the configuration needed to keep the components above the Internet layer running. For example:

Name Service Configuration

This is the configuration the host needs to resolve names. It includes the addresses of name resolution servers: IEN 116 [IEN116], Domain Name System (DNS), Windows Internet Name Service (WINS), Internet Storage Name Service (iSNS) [RFC4171] [RFC4174], and Network Information Service (NIS) servers [RFC3898]. It also covers setting name resolution parameters like the DNS domain and search list [RFC3397], and the NetBIOS node type. It might also include sending or setting the host's own name 💖 Link-local name resolution services, like NetBIOS [RFC1001], Link-Local Multicast Name Resolution (LLMNR) [RFC4795], and multicast DNS (mDNS) [mDNS], typically don't need any configuration 🌸

Once the host finishes name service configuration, it can resolve names using name resolution protocols that do need configuration. That lets it talk to off-link hosts whose IP addresses it doesn't know. To the extent that name services needing configuration get used for service discovery, it also lets the host find services on the network or elsewhere 👑 Name service parameters can be given per interface, but their configuration usually changes how the host behaves overall ✨

Time Service Configuration

Time service configuration covers setting up servers for protocols like the Simple Network Time Protocol (SNTP) and the Network Time Protocol (NTP). Accurate time can matter a lot for the apps on the host (including security services), so configuring time servers can be a prerequisite for higher-layer operation. It's typically not required for Internet-layer configuration, though 🫶 Time service parameters can be given per interface, but their configuration usually affects the whole host 🍓

Other service configuration

This can include finding more servers and devices, like printers and Session Initiation Protocol (SIP) proxies 🌈 This configuration usually applies to the entire host 💅

2. Principles ✨

This section covers the basic principles of Internet host configuration 💜

2.1. Minimize Configuration 🎀

Okay so, anything that can be configured can be misconfigured 🙈 Section 3.8 of "Architectural Principles of the Internet" [RFC1958] says: "Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually."

So the goal is to cut down on configuration errors by having parameters computed automatically (or at least having reasonable defaults) whenever possible ✨ For example, the Path Maximum Transmission Unit (PMTU) can be discovered, as described in "Packetization Layer Path MTU Discovery" [RFC4821], "TCP Problems with Path MTU Discovery" [RFC2923], "Path MTU discovery" [RFC1191], and "Path MTU Discovery for IP version 6" [RFC1981] 🦋

A protocol with a ton of configurable parameters is basically asking for trouble 💀 More knobs means more chances to mess something up, and that leads to failures or just sub-optimal operation. Cutting down on configurable parameters helps lower that risk. And when parameters are needed or wanted anyway, protocols can protect us from human error by making them self-configuring, like using capability negotiation within the protocol or automatically discovering other hosts that run the same protocol 💜

2.2. Less Is More 🌸

The availability of standardized, simple mechanisms for general-purpose Internet host configuration is highly desirable. "Architectural Principles of the Internet" [RFC1958] also says, "Performance and cost must be considered as well as functionality" and "Keep it simple. When in doubt during design, choose the simplest solution." Iconic advice honestly 👑

Protocol support has to fit many kinds of devices, so it's important to keep the footprint small 📉 IP-based protocols run on everything from supercomputers to tiny low-cost devices running "embedded" operating systems. Since the resources (e.g., memory and code size) available for host configuration may be very small, it's really useful for a host to configure itself in the simplest way possible 🧚

One example that's kinda wild is IP support in preboot execution environments 😭 Boot configuration is required on hosts that haven't fully booted yet, so preboot code often has to run from Read Only Memory (ROM) with minimal memory available. Lots of hosts don't have enough room in that ROM for even a simple implementation of TCP, so in the Preboot Execution Environment (PXE), getting a boot image is done with the User Datagram Protocol over IP (UDP/IP) [RFC768] instead. That's one reason Internet-layer configuration mechanisms usually depend only on IP and UDP. After the boot image is obtained, the host has the full TCP/IP facilities available, including support for reliable transport protocols, IPsec, etc. ✨

To keep things less complicated, Internet-layer configuration mechanisms should avoid depending on higher layers 🫶 Embedded devices can be severely limited in how much code fits in their ROM, so a configuration mechanism that needs higher-layer facilities might be totally unusable on those devices. It also can't be guaranteed that all Internet-layer facilities will be there. For example, the minimal version of IP in a host's boot ROM may not implement IP fragmentation and reassembly 🙈

2.3. Minimize Diversity 🌈

The number of host configuration mechanisms should be minimized. Having lots of different ones causes several problems, so let's go through them 💅

Interoperability

As configuration diversity increases, it becomes likely that a host will not support the configuration mechanism(s) available on the network it has attached to, which creates interoperability problems 😬

Footprint

For maximum interoperability, a host would need to implement all configuration mechanisms used on all the link layers it supports. That makes the footprint bigger, which is a burden for embedded devices. It also leads to lower quality, because testing resources (both formal testing and real-world operational use) get spread more thinly. The more different configuration mechanisms a device supports, the less testing each one is likely to get 📉

Redundancy

To support diversity in host configuration mechanisms, operators would need to run multiple configuration services so that hosts connecting to their networks can configure themselves. That's an extra expense for very little benefit 💸

Latency

As configuration diversity increases, hosts supporting multiple configuration mechanisms may spend more and more effort figuring out which mechanism(s) are supported. That adds to configuration latency ⏳

Conflicts

Whenever multiple mechanisms are available, it's possible that multiple configurations will come back. To handle that, hosts would need to merge potentially conflicting configurations. This would require conflict-resolution logic, such as ranking potential configuration sources, which makes implementations more complex 🤯

Additional traffic

To limit configuration latency, hosts may simultaneously try to obtain configuration through multiple mechanisms. This can increase on-the-wire traffic, both from using multiple mechanisms and from retransmissions within configuration mechanisms that aren't implemented on the network 📡

Security

Supporting multiple configuration mechanisms increases the attack surface without any benefit. Not it 🚨

2.4. Lower-Layer Independence 🦋

"Architectural Principles of the Internet" [RFC1958] states, "Modularity is good. If you can keep things separate, do so." Hosts are increasingly supporting multiple network access mechanisms, including dialup, wireless, and wired local area networks, wireless metropolitan and wide area networks, and so on 🌐 All that proliferation makes it desirable for hosts to configure themselves on multiple networks without adding configuration code for each new link layer 💖

So it's highly desirable for Internet host configuration mechanisms to be independent of the underlying lower layer. Only the link-layer protocol (whether it's a physical link or a virtual tunnel link) should be explicitly aware of link-layer parameters, although those link-layer parameters may be configured by general Internet-layer mechanisms. Lower-layer dependencies increase the likelihood of interoperability problems and add Internet-layer configuration mechanisms that hosts need to implement 😵‍💫

The best way to avoid lower-layer dependencies is to keep Internet host configuration above the link layer, which lets configuration be handled for any link layer that supports IP. To provide media independence, Internet host configuration mechanisms should be link-layer protocol independent 🧚

There are examples of Internet-layer configuration living inside the link layer, like PPP IPv4CP [RFC1332] and "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)" [3GPP-24.008]. But this approach has downsides. You get the extra complexity of implementing different mechanisms on different link layers, and it's hard to add new higher-layer parameters that would require defining a mechanism in each link-layer protocol 🙃

Take "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses" [RFC1877]. It was developed before the definition of the DHCPINFORM message in "Dynamic Host Configuration Protocol" [RFC2131]. Back then, Dynamic Host Configuration Protocol (DHCP) servers hadn't been widely implemented on access devices or deployed in service provider networks, so it made sense at the time 🕰️ IPv4CP was appropriate in 1992, but it shouldn't be treated as an example that new link-layer technologies should copy. In fact, "IANA Considerations for the Point-to-Point Protocol (PPP)" [RFC3818] changed the allocation of PPP numbers (including IPv4CP extensions) so they're no longer "first come first served", in order to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value" 🔥

In IPv6, link-layer-independent mechanisms such as stateless autoconfiguration [RFC4862] and stateless DHCPv6 [RFC3736] are available. PPP IPv6CP [RFC5072] configures an Interface-Identifier that's similar to a Media Access Control (MAC) address. This lets PPP IPv6CP avoid duplicating DHCPv6 functionality 👑

However, Internet Key Exchange Version 2 (IKEv2) [RFC4306] uses the same approach as PPP IPv4CP, defining a Configuration Payload for Internet host configuration for both IPv4 and IPv6. The IKEv2 approach does reduce the number of packet exchanges, but "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode" [RFC3456] points out that leveraging DHCP has advantages in terms of address management integration, address pool management, reconfiguration, and fail-over 🤔

Extensions to link-layer protocols for Internet-, transport-, or application-layer configuration (including server configuration) should be avoided. Those extensions can negatively affect the properties of a link as seen by higher layers 🚫 For example, if a link-layer protocol (or tunneling protocol) configures individual IPv6 addresses and precludes using any other addresses, then applications that want to use privacy extensions [RFC4941] may not work well. Similar issues may come up for other address types, like Cryptographically Generated Addresses [RFC3972] 🙈

Avoiding lower-layer dependencies is still desirable even when the lower layer is link independent. For example, the Extensible Authentication Protocol (EAP) may be run over any link that satisfies its requirements (see Section 3.1 of [RFC3748]), but many link layers don't support EAP. So Internet-layer configuration mechanisms that depend on EAP wouldn't be usable on links that support IP but not EAP 🥺

2.5. Configuration Is Not Access Control 🔐

Network access authentication and authorization is a totally separate problem from Internet host configuration. So network access authentication and authorization is best handled independently of the Internet and higher-layer configuration mechanisms 💅

An Internet- or higher-layer protocol authenticating clients is appropriate for preventing resource exhaustion of a scarce resource on the server (like IP addresses or prefixes). It is not for stopping hosts from getting access to a link 🚪 If the user can configure the host manually, then requiring authentication before getting configuration parameters (like an IP address) has little value. Network administrators who want to control access to a link can do that better with technologies like Port-Based Network Access Control [IEEE-802.1X]. Note that client authentication is not required for Stateless DHCPv6 [RFC3736], since it doesn't result in allocating any limited resources on the server 🫧

3. Additional Discussion ✨

3.1. Reliance on General-Purpose Mechanisms 🎀

okay so protocols should either be self-configuring (especially where fate sharing is important 🫶) or use general-purpose configuration mechanisms, like DHCP or a service discovery protocol (more on that in Section 3.2 🧚). and the choice should be made with the architectural principles from Section 2 in mind ✨

taking into account the general-purpose configuration mechanisms that already exist, we honestly don't see much need to build new ones 💅

when you're defining a new host parameter, first ask yourself if configuration is even necessary (see Section 2.1) 🙈

if it is necessary, then along with fate sharing (see Section 3.2.1), protocol designers should think about:

  1. The organizational implications for administrators. For example, routers and servers are often run by different groups of people, so configuring a router with server parameters might need cross-group collaboration 🤝
  2. Whether the need is to configure a set of interchangeable servers or to select a particular server that meets a set of criteria. See Section 3.2.
  3. Whether IP address(es) should be configured, or name(s). See Section 3.3.
  4. If IP address(es) are configured, whether IPv4 and IPv6 addresses should be configured at the same time or separately. See Section 3.4.
  5. Whether the parameter is a per-interface or a per-host parameter. For example, configuration protocols such as DHCP run on a per-interface basis, so they're a better fit for per-interface parameters 🦋
  6. How per-interface configuration affects host-wide behavior. For example, whether the host should pick a subset of the per-interface configurations, or whether the configurations are to be merged, and if so, how that's done. See Section 3.5. 👑

3.2. Relationship between IP Configuration and Service Discovery 🌈

okay this part is so good 😭 higher-layer configuration often includes configuring server addresses, so the question is how that's different from "service discovery" as offered by service discovery protocols like "Service Location Protocol, Version 2" (SLPv2) [RFC2608] or "DNS-Based Service Discovery" (DNS-SD) [DNS-SD].

in Internet host configuration mechanisms like DHCP, if you get multiple server instances, they're treated as interchangeable. like in a list of time servers, they're all interchangeable because they all do the exact same job, which is telling you the current time ⏰. in a list of local caching DNS servers, they're interchangeable too, because they should all give you the same answer to any DNS query. service discovery protocols are different, though 👀. there, a host wants to find a server that meets a specific set of criteria, and that can change from request to request. when you're printing a document, it's not like any printer will do. the speed, the capabilities, and the physical location of the printer all matter to the user 🖨️

information learned through DHCP is usually learned once, at boot time, and after that it might only get updated now and then (like on DHCP lease renewal), or never at all 💤. so DHCP is a great fit for info that's pretty static and doesn't change over those time windows. boot-time discovery of server addresses works well for service types where there are a small number of interchangeable servers that a lot of clients care about. for example, listing time servers in a DHCP packet makes sense, because an organization might only have two or three time servers, and most hosts can use that service. listing every printer or file server in an organization is way less useful, though, because the list could have hundreds or thousands of entries, and on any given day a user might not use any of them 🙃

service discovery protocols can also find servers on the Internet, not just ones inside the local administrative domain. for example, check out "Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV" [RFC3832] and DNS-Based Service Discovery [DNS-SD] 🌍. Internet host configuration mechanisms like DHCP, on the other hand, usually assume that the server or servers in the local administrative domain hold the authoritative set of information.

for the service discovery problem (where the criteria change on a per-request basis, even from the same host), protocols should either be self-discovering (if fate sharing is critical) or use a general-purpose service discovery mechanism ✨

to avoid depending on multicast routing, a host needs to either limit discovery to services on the local link, or find the location of a Directory Agent (DA). since the DA might not be available on the local link, service discovery beyond the local link usually depends on some mechanism for configuring the DA address or name. because of that, service discovery protocols usually can't be relied on for getting basic Internet-layer configuration, though they can be used to get higher-layer configuration parameters 💖

3.2.1. Fate Sharing 🔗

if a server (or a set of servers) is needed to get a set of configuration parameters, "fate sharing" (Section 2.3 of [RFC1958]) is preserved when those parameters can't be usefully used without those servers being available. in that case, grabbing the parameters some other way doesn't help much, because they still can't be used if the required servers are down 😤. the chance of wrong info getting configured is lower when only one machine is authoritative for the info (so there's no need to keep several authoritative servers in sync). for example, learning default gateways through Router Advertisements gives perfect fate sharing. gateway addresses can only be obtained if they can actually be used 🌸. similarly, getting DNS server configuration from a DNS server gives you fate sharing, because you can only get that config if the DNS server is up.

fate sharing is a great property for a configuration mechanism to have, but sometimes it just isn't possible 🥲. when service discovery is used to find services on the local link, the protocols usually do provide fate sharing, because the hosts providing the service info also provide the services. but that stops being true once a Directory Agent (DA) is helping with service discovery. first of all, the DA's list of working servers might not be current, so the DA could hand clients service info that's out of date. for example, the DA's reply to a client's service discovery query might have stale info about servers that aren't running anymore. recently added servers might not have registered with the DA yet either. and using a DA for service discovery adds a dependency on whether the DA is operational, even though the DA usually isn't involved in delivering the service itself 🫠

other server-based configuration mechanisms, like DHCP, have similar limitations. DHCP servers typically don't check whether the configuration info they provide is still live, and they don't automatically discover new configuration info. so there's no guarantee that the configuration info stays current 😬

Section 3.3 of "IPv6 Host Configuration of DNS Server Information Approaches" [RFC4339] talks about using well-known anycast addresses to discover DNS servers. anycast addresses enable fate sharing, even when the anycast address is provided by an unrelated server 🧚. but to be universally useful, this approach would need one or more well-known anycast addresses allocated for each service. configuring more than one anycast address is a good idea too, because it lets the client fail over faster than routing protocol convergence would allow 🏃‍♀️

3.3. Discovering Names vs. Addresses 🎀

when you're discovering servers other than name resolution servers, you can either discover the IP addresses of the server(s), or discover names, where each name may resolve to a list of addresses 📇

getting the list of addresses directly is usually more efficient, since it skips the extra name resolution steps and the latency that comes with them ⚡. on the other hand, if servers are mobile, the name-to-address binding can change, so you'd need a fresh set of addresses. when the configuration mechanism doesn't support fate sharing (like DHCP), providing a name instead of an address can make things simpler, as long as the server's new address gets updated in the DNS (manually or automatically). in that case, there's no need to redo parameter configuration, since the name is still valid 🙌. where fate sharing is supported (like with service discovery protocols), you can get a fresh address by re-initiating parameter configuration.

when you're providing IP addresses for a set of servers, it's really useful to be able to tell which IP addresses belong to which server 💜. if a server's IP address is unreachable, this lets the host try the IP address of a different server instead of another IP address of the same server, in case the server itself is down. that's only possible if the host can tell which addresses belong to the same server 🫶

3.4. Dual-Stack Issues 🌈

okay so one big reason to grab a list of server addresses that are all interchangeable is fault tolerance 🛟. If one or more servers stop responding, the host can just try a different one. Hosts usually try the addresses in turn and only move on to the second and later ones if the first doesn't respond fast enough. So it helps a lot to sort the list by how likely each address is to work 🏃‍♀️💨. And if your host speaks both IPv4 and IPv6, you really want both kinds of server addresses in one single list 💖. If you get the IPv4 and IPv6 addresses in separate lists and nothing says which server each address belongs to, the host has to use a heuristic to mash the lists together, and that's messy 😵‍💫.

Let's say there are two servers, A and B, and each one has an IPv4 address and an IPv6 address. Say the first address the host should try is the IPv6 address of server A 🎀. If that one fails, the second address it should try would generally be the IPv4 address of server B. Why? Because the failure could be because server A is down, OR because of a problem with the host's IPv6 address, OR because of a connectivity problem to server A 🤷‍♀️. Trying the IPv4 address next is the move, because the IPv4 address is reachable independently of all of those possible failure causes 🧠✨.

Now, if the IPv4 server list came from a different source than the IPv6 list, the host trying to merge them would have no clue which IPv4 addresses go with the same server as the IPv6 address it just tried 🙈. There are two ways to fix that. You can explicitly label which addresses belong to which server, or, the simpler option, you configure the host with one combined list of both IPv4 and IPv6 addresses 🫶. Heads up, the same problem can pop up with any mechanism for getting server IP addresses, like DHCP, DNS, and so on 💀.

Configuring a combined list gives the configuration mechanism control over the ordering of addresses 👑. Compare that to configuring a name and letting the host resolver decide the address list order. For more on dual-stack issues in the DHCP context, check out "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues" [RFC4477] 📚💅.

3.5. Relationship between Per-Interface and Per-Host Configuration 🦋

this one is so interesting, bestie 🤩. Parameters that get configured or acquired per interface can end up affecting how the host behaves as a whole 🧚. If only one configuration can be applied to the host, the host might need to rank the per-interface configuration somehow, like most trusted to least trusted 👑. And if the host has to merge per-interface configuration into one host-wide configuration, it might need to take the union of the per-host configuration parameters and put them in some order, like highest-speed interface to lowest-speed interface 🚀. Which procedure gets used, and how it's pulled off, can change depending on the parameter being configured 🔥. Here are some examples:

Boot service configuration

While boot service configuration can be provided on multiple interfaces, a given host may be limited in how many boot loads it can handle at once 😭. For example, a host that doesn't support virtualization might only handle one boot load at a time, or a host that can run N virtual machines might only handle up to N simultaneous boot loads 💻. So the host might have to pick which boot load(s) it will act on from the ones configured per interface 🎯. That means it has to prioritize them, like most to least trusted 🫶.

Name service configuration

Name service configuration is provided per interface, but name resolution configuration usually affects the host as a whole 🌸. For example, the host looks at the DNS server addresses and searchlist parameters configured on each interface, and then decides what sequence of name service queries gets sent out on which interfaces 🔍✨.

Here's the thing: the algorithms that turn per-interface configuration into per-host behavior can affect interoperability, so implementers really need to understand them 🧠. That's why we recommend that documents defining per-interface mechanisms for acquiring per-host configuration (like DHCP or IPv6 Router Advertisement options) include guidance on dealing with multiple interfaces 💖. That guidance may cover the following items:

  1. Merging. How are per-interface configurations combined to produce a per-host configuration? Is a single configuration selected, or is the union of the configurations taken?
  2. Prioritization. Are the per-interface configurations prioritized as part of the merge process? If so, what are some of the considerations to be taken into account in prioritization?

4. Security Considerations 🔐

okay, this part is SERIOUS, bestie 😤. Secure IP configuration is genuinely hard 💀. Along with denial-of-service and man-in-the-middle attacks, attacks on configuration mechanisms may target particular parameters 🚨. For example, attackers may go after DNS server configuration so they can pull off phishing or pharming attacks like the ones described in "New trojan in mass DNS hijack" [DNSTrojan] 😱. There are a bunch of issues with various classes of parameters, as discussed in Section 2.6, Section 4.2.7 of "IPv6 Neighbor Discovery (ND) Trust Models and Threats" [RFC3756], Section 1.1 of "Authentication for DHCP Messages" [RFC3118], and Section 23 of "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3315] 📖. Given all those potential vulnerabilities, hosts often limit DHCP option support to the minimum set needed to provide basic TCP/IP configuration 🧱.

Here's where it gets really scary 🫣. Boot configuration decides which boot image the host runs, so a successful attack on boot configuration could let an attacker take complete control of a host 👾. That's why it's especially important to secure boot configuration 🔒. Approaches to boot configuration security are described in "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol" [RFC4173] and "Preboot Execution Environment (PXE) Specification" [PXE] 🛡️.

4.1. Configuration Authentication 🪪

ngl, the techniques available for securing Internet-layer configuration are pretty limited 😩. Technically you can do a very limited subset of IP networking without an IP address, but the capabilities are seriously restricted 🥺. A host without an IP address can't receive normal unicast IP packets, only IP packets sent to the broadcast address or a multicast address 📡. Once you configure an IP address, IP fragmentation is enabled. Packets sent from the unknown address can't be reliably reassembled, because fragments from multiple hosts using that unknown address might get reassembled into a single IP packet 🧩💀. Without an IP address, you also can't use security facilities like IPsec, specified in "Security Architecture for the Internet Protocol" [RFC4301], or Transport Layer Security (TLS) [RFC5246] 🙅‍♀️. So configuration security is typically built into the configuration protocols themselves 🫶.

PPP [RFC1661] doesn't support secure negotiation within IPv4CP [RFC1332] or IPv6CP [RFC5072], so an attacker with access to the link can subvert the negotiation 😭. IKEv2 [RFC4306], on the other hand, provides encryption, integrity, and replay protection for configuration exchanges 💖.

Where configuration packets are only expected to come from particular links or particular hosts, filtering can help control configuration spoofing 🧹. For example, a wireless access point usually has no reason to forward broadcast DHCP DISCOVER packets to its wireless clients, and it usually should drop any DHCP OFFER packets it receives from those wireless clients 🙅‍♀️. Generally speaking, wireless clients should be requesting addresses from the network, not offering them 🎀. To prevent spoofing, communication between the DHCP relay and servers can be authenticated and integrity protected using a mechanism such as IPsec 🔐.

Internet-layer secure configuration mechanisms include SEcure Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address autoconfiguration [RFC4862], or DHCP authentication for stateful address configuration ✨. DHCPv4 [RFC2131] initially didn't include security support. That got added in "Authentication for DHCP Messages" [RFC3118] 🛠️. DHCPv6 [RFC3315] included security support from the start 👑. Still, DHCP authentication is not widely implemented for either DHCPv4 or DHCPv6 😭.

Higher-layer configuration can use a much wider range of security techniques 🌈. When DHCP authentication is supported, the higher-layer configuration parameters provided by DHCP can be secured 🔒. And even if a host doesn't support DHCPv6 authentication, higher-layer configuration via Stateless DHCPv6 [RFC3736] can still be secured with IPsec 💅.

There can be possible exceptions where security facilities aren't available until later in the boot process 🙈. It may be hard to secure boot configuration even after the Internet layer has been configured, if security functionality only becomes available after boot configuration is finished 😵. For example, it's possible that Kerberos, IPsec, or TLS won't be available until later in the boot process. See "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol" [RFC4173] for discussion 📖.

⚠️ Where public key cryptography is used to authenticate and integrity-protect configuration, hosts need to be configured with trust anchors so they can validate received configuration messages 🔑. For a node that visits multiple administrative domains, acquiring the required trust anchors may be difficult 🥺.

5. Informative References ✨

okay so this is the reading list 📚 every single thing here is a "go read this if you want the full story" kind of source. Some are super old classics (IEN 116 from 1979, the OG DNS vibes 🦖), some are the big standards everyone builds on, and a couple are news articles about DNS getting hijacked, which is honestly a whole mood 💀

  • [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)", June 2003.
  • [DNSTrojan] Goodin, D., "New trojan in mass DNS hijack", The Register, December 5, 2008, http://www.theregister.co.uk/2008/12/05/new_dnschanger_hijacks/
  • [IEN116] J. Postel, "Internet Name Server", IEN 116, August 1979, http://www.ietf.org/rfc/ien/ien116.txt
  • [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, December 2004.
  • [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, September 2008.
  • [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, September 2008.
  • [PXE] Henry, M. and M. Johnston, "Preboot Execution Environment (PXE) Specification", September 1999, http://www.pix.net/software/pxeboot/archive/pxespec.pdf
  • [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
  • [RFC1001] NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, and End-to-End Services Task Force, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods", STD 19, RFC 1001, March 1987.
  • [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
  • [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
  • [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
  • [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
  • [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, December 1995.
  • [RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
  • [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
  • [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
  • [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
  • [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
  • [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
  • [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
  • [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
  • [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
  • [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
  • [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
  • [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
  • [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
  • [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
  • [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
  • [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point Protocol (PPP)", BCP 88, RFC 3818, June 2004.
  • [RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, "Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV", RFC 3832, July 2004.
  • [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
  • [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
  • [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
  • [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
  • [RFC4171] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.
  • [RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis, "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol", RFC 4173, September 2005.
  • [RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service", RFC 4174, September 2005.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
  • [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.
  • [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, May 2006.
  • [RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)", RFC 4578, November 2006.
  • [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
  • [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
  • [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
  • [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
  • [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [STD3] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

Appendix A. Acknowledgments 💖

Huge thank-yous to Elwyn Davies, Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola, James Kempf, Ted Hardie, and Alfred Hoenes, who all provided valuable input on this document 🫶🌸

Appendix B. IAB Members at the Time of This Writing 👑

These were the IAB members when this was written:

  • Loa Andersson
  • Gonzalo Camarillo
  • Stuart Cheshire
  • Russ Housley
  • Olaf Kolkman
  • Gregory Lebovitz
  • Barry Leiba
  • Kurtis Lindqvist
  • Andrew Malis
  • Danny McPherson
  • David Oran
  • Dave Thaler
  • Lixia Zhang

Authors' Addresses 🦋

Here's where to find the authors:

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: bernarda@microsoft.com


Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: dthaler@microsoft.com


Loa Andersson
Ericsson AB

EMail: loa.andersson@ericsson.com


Stuart Cheshire
Apple Computer, Inc.
1 Infinite Loop
Cupertino, CA 95014

EMail: cheshire@apple.com
📦 where this page comes from