RFC 6419
Current Practices for Multiple-Interface Hosts
RFC 6419: Current Practices for Multiple-Interface Hosts 💖
okay bestie, let's get into it 🎀
This one is an Informational doc (not a Standards Track spec) from November 2011, written by M. Wasserman of Painless Security, LLC and P. Seite of France Telecom - Orange 🦋. It's published under ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's just a standalone snapshot of what's happening out there. 🌸
Abstract
More and more hosts are running in multiple-interface environments, so this doc is basically a roundup of what people are doing about it right now ✨ It also goes deep on how some common operating systems handle the problems that come with that setup 💅
Status of This Memo
Okay, the legal-ish bit, but it matters 🙈 This is not an Internet Standards Track spec. It's just published for info. 🧚
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is up for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 💜
If you want the latest status, any errata, or a way to send feedback, check out http://www.rfc-editor.org/info/rfc6419 🌈
Copyright Notice
Copyright (c) 2011 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) as they stand on the date of publication. Please actually read these, because they spell out your rights and restrictions for this doc 🫶 If you pull Code Components out of this doc, they have to include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⚠️
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Summary of Current Approaches . . . . . . . . . . . . . . . . 3
2.1. Centralized Connection Management . . . . . . . . . . . . 3
2.2. Per-Application Connection Settings . . . . . . . . . . . 4
2.3. Stack-Level Solutions to Specific Problems . . . . . . . . 4
2.3.1. DNS Resolution Issues . . . . . . . . . . . . . . . . 5
2.3.2. First-Hop Selection . . . . . . . . . . . . . . . . . 5
2.3.3. Address Selection Policy . . . . . . . . . . . . . . . 5
3. Current Practices in Some Operating Systems . . . . . . . . . 6
3.1. Mobile Handset Operating Systems . . . . . . . . . . . . . 6
3.1.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . 7
3.1.2. Microsoft Windows Mobile and Windows Phone 7 . . . . . 9
3.1.3. RIM BlackBerry . . . . . . . . . . . . . . . . . . . . 10
3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 11
3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 12
3.1.6. Leadcore Technology Arena . . . . . . . . . . . . . . 13
3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 14
3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 14
3.2.1.1. First-Hop Selection . . . . . . . . . . . . . . . 14
3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 14
3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 15
3.2.2. Linux and BSD-Based Operating Systems . . . . . . . . 16
3.2.2.1. First-Hop Selection . . . . . . . . . . . . . . . 16
3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 16
3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 17
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 191. Introduction ✨
Multiple-interface hosts run into a bunch of challenges that single-interface hosts never have to deal with. Some of those are laid out in the multiple interfaces (MIF) problem statement [RFC6418] 🧠 This doc is about how current implementations actually deal with the problems that the MIF problem statement names 💅
Publicly available info about the multiple-interface solutions in some widely used operating systems is collected here, covering both mobile handset and desktop OSes. That includes Nokia S60 [S60], Microsoft Windows Mobile [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android [ANDROID], Microsoft Windows, Linux, and BSD-based operating systems 🌸
2. Summary of Current Approaches 🦋
This section gives the tea on the current approaches for fixing the multiple-interface issues from the MIF problem statement [RFC6418]. They sort into three big buckets 👑
- Centralized connection management
- Per-application connection settings
- Stack-level solutions to specific problems
2.1. Centralized Connection Management
Mobile handset OSes commonly use a centralized connection manager. It picks the network interface based on what the app or the user says 💅 Connection managers usually keep the problem limited to picking an interface, though, and they don't handle picking the provisioning domain, which is defined in [RFC6418] 🙈 The info the connection manager uses might be programmed into an app or provisioned for the whole handset. If it doesn't have enough info to pick an interface, the connection manager asks the user to choose from the options they've got 🫶
Routing tables usually aren't used for interface selection when a connection manager is in charge. That's because the selection criteria aren't purely IP-based. They also depend on other properties of the interface, like cost, type, and so on 💜 Plus, a multiple-interface host often ends up with overlapping private IPv4 address spaces, which makes it really hard to pick an interface just by prefix matching 😭
2.2. Per-Application Connection Settings
On mobile handsets, apps are often part of the decision about which interface and related config info gets used ✨ Sometimes the app picks the interface directly. Other times, the app hands more abstract info to a connection manager, and that manager makes the final call 🎀
2.3. Stack-Level Solutions to Specific Problems
On most desktop OSes, multiple-interface problems get handled in the stack and its related components. They use system-level config info and don't get any input from apps or users 🌈 These solutions tend to line up pretty nicely with the problems in the problem statement:
- DNS resolution issues
- Routing
- Address selection policy
Desktop systems get their config info from one of these sources: DHCP, router advertisements, proprietary config systems, or manual config. These systems all accept IP address assignment on a per-interface basis, but they disagree on which info can be assigned per interface and which info can only be set for the whole system 🧚
When a host gets more than one set of info, these systems usually prefer the info that came in on the "primary" interface. How you designate the "primary" interface depends on the system 💖
Honestly, there's very little consistency in how desktop OSes handle multiple sets of config info. Even different versions of the same OS, or different software packages on the same OS, can do things differently 💀 With all those differences, it's not clear that any of them give a totally satisfying experience in multiple-interface environments 😭
The next sections talk about some of the solutions used in each of the areas the MIF problem statement raised 🔥
2.3.1. DNS Resolution Issues
Desktop OSes don't agree much on how they handle the DNS server list. Some support per-interface DNS server lists, and others only support one system-wide list 🌸
On hosts with per-interface DNS server lists, different mechanisms decide which DNS server gets queried for a given query. Usually, the first DNS server on the "primary" interface gets asked first, and if no answer comes back, it backs off and tries the other servers 🦋
Systems with a single system-wide list also differ in how they choose which DNS server to use when they receive more than one DNS server list to configure. For example, that can happen with DHCP on multiple interfaces. Some go with the info that came in on the "primary" interface, while others use either the first or the last DNS server list configured 💅
2.3.2. First-Hop Selection
Desktop OSes also handle routing info differently. Every system keeps some kind of routing cache, to deal with redirects and/or statically configured routes. But most packets get routed based on the configured default gateway info 🎀
Some systems let you configure different default router lists for different interfaces. These systems always pick the default gateway on the interface with the lowest routing metric. When two or more interfaces share the same routing metric, the behavior is different from system to system 👑
Most systems don't let you configure more than one default router list. Instead, they use either the first or last default router list configured, and/or the router list on the "primary" interface 🫶
2.3.3. Address Selection Policy
Desktop hosts are a little more consistent when it comes to address selection 🌈 Apps usually supply the destination address for an outgoing packet, and then the IP stack is in charge of picking the source address 💜
IPv6 has a specific source address selection mechanism defined in [RFC3484], and several systems use that same mechanism, with similar support for IPv4 🧚 However, a lot of systems don't give you any way to update this default policy, and there's no standard way to do it 😭
Sometimes the routing decision (including which interface to use) happens before source address selection, and the source address is picked from the outbound interface. Other times, source address selection happens before outbound interface selection, or independently of it 🔥
3. Current Practices in Some Operating Systems ✨
okay bestie, this section is all about what real operating systems were actually doing 🧚 the info comes from people who know these OSes inside out 🫶 and the authors and the IETF take no position on any of them 💅 (other OSes exist too, obvi). heads up though: this is a snapshot of what was current when the doc was written 📸 earlier and later versions might act totally different, so check the References section for the original docs if you want the deets 🌸
3.1. Mobile Handset Operating Systems
phones run like a dozen apps at once 📱 and every single one has its own networking vibe 😭 Figure 1 shows the main case: a cellular device using WLAN for web browsing and GPRS for MMS. another common combo is a real-time VoIP call on one interface while web browsing runs on another, or global internet on one interface and corporate VPN access on another 💜
Web server MMS Gateway
| |
-+--Internet---- ----Operator network--+-
| |
+-------+ +-------+
|WLAN AP| | GGSN |
+-------+ +-------+
| +--------+ |
+--------|Cellular|--------+
|device |
+--------+
A Cellular Device with Two Network Interfaces
Figure 1different access techs need different settings 🎀 WLAN needs an SSID, GPRS needs the APN of the GGSN, plus a few other parameters. and different accesses often lead to different destination networks (internet, intranet, cellular network services, etc.) 🌈
3.1.1. Nokia S60 3rd Edition, Feature Pack 2
S60 is a software platform for mobile devices running on the Symbian operating system (OS) 📲 it uses the concept of an Internet Access Point (IAP) [S60], which holds everything needed to open a network connection using one specific access tech. a device can have a bunch of IAPs for different networks and settings (multiple WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth) 🍓 there can also be 'virtual' IAPs that define the stuff needed to set up a tunnel (like for VPN) 🦋
for each app, the right IAP has to be picked at the moment the app needs connectivity 😤 this is super important, because the wrong IAP might not support the app or reach where it's trying to go. like, an MMS app needs the correct IAP to reach the MMS Gateway, which usually isn't reachable from the public Internet 💀 another example: an app might need its corporate VPN's IAP to reach internal corporate servers 🏢 binding apps to IAPs also dodges a few problems. one is picking the right DNS server when split DNS is in play (an app uses the DNS server list from its bound IAP). another is overlapping private IPv4 address spaces across interfaces (each app uses the default routes from its bound IAP) 🙌
if several apps use the same IAP, the underlying network connection can usually be shared 🤝 which happens a lot when multiple Internet-using apps are running at the same time.
the IAP for an app can be picked in three ways:
- Statically: for example, from a configuration interface, via client provisioning/device management system, or at build-time.
- Manually by the user: for example, each time an app starts, the user may be asked to pick the IAP. this might be needed if someone sometimes wants to reach their corporate intranet and other times just wants direct Internet access 🙃
- Automatically by the system: after the destination network has been selected statically or dynamically 🤖
static is totally fine for certain apps, like MMS, where the network operator can provision the config and it doesn't change much 📦 manual selection works but can feel like a chore to the user 😩 and automatic selection needs some way of knowing which destination network the user, or an app, is trying to access 🔍
S60 3rd Edition, Feature Pack 2 introduces Service Network Access Points (SNAPs), which group together IAPs that lead to the same destination ✨ this means an app can statically or manually pick the destination network, and the OS handles picking the best of the available IAPs within that SNAP 👑
when SNAPs are used, the OS can tell apps when a preferred IAP leading to the same destination shows up (like when you wander into range of your home WLAN) or when the IAP currently in use goes away 📶 if that happens, apps have to reconnect through another IAP (like when you leave your home WLAN's range and have to switch to cellular) 🚶♀️
S60 3.2 doesn't support RFC 3484 for source address selection 🙅♀️ apps are tightly bound to whichever network interface was selected for them or by them 🔗 for example, an app might be connected through an IPv6 3G connection, an IPv4 3G connection, a WLAN connection, or a VPN connection. the app can switch between these, but it only ever uses one at a time. if the interface happens to be dual-stack, IPv4 wins over IPv6 🫶
DNS config is per-interface, so an app bound to an interface always uses that interface's DNS settings 🗂️ which means the device remembers this info separately for each interface.
S60 3.2 handles totally overlapping address spaces 🌀 every interface can even have the same IPv4 address configured without any issues, because the interfaces are kept totally separate from each other. this means interface selection has to happen at the application layer, since from the network layer's point of view, the device isn't multihomed in the IP sense 🧩
see the S60 source documentation for more details and screenshots [S60] 📸
3.1.2. Microsoft Windows Mobile and Windows Phone 7
Microsoft Windows Mobile uses a connection manager [WINDOWSMOBILE] to handle multiple network connections 🎛️ this setup centralizes and automates connection setup and management, and it can automatically pick a connection, dial in automatically or on the user's say-so, and optimize connection and shared resource use 💅 the connection manager re-checks whether its connection choice is still valid, now and then 🔄 it weighs stuff like cost, security, bandwidth, error rate, and latency when deciding 🧠
the connection manager picks the best connection for an app based on the destination network the app wants to reach 🎯 it chooses between available physical and virtual connections (like VPN, GPRS, WLAN, and wired Ethernet) that are known to reach that destination network, and the choice is based on the cost of each connection 💸 apps get bundled onto the same connection whenever possible. but if a connection can't be shared and there's a conflict, higher-priority apps win and lower-priority ones lose connectivity until the conflict clears 👑😭
while things are running, the connection manager opens new connections as needed and disconnects unused or idle ones 🧹
to save battery and bandwidth, the connection manager lets apps sync up their connection usage by registering their needs for periodic connectivity 🔋 an app gets notified when a suitable connection is available for it to use 🔔
compared to Windows Mobile connection management, Windows Phone 7 updates the routing functionality for when the terminal can be attached to several interfaces at once 🛣️ Windows Phone 7 picks the first hop for the interface with the lower metric. when there are multiple interfaces, the applications system will, by default, choose from an ordered list of available interfaces. the default policy prefers wired over wireless and WLAN over cellular 📡 so if an app wants to use cellular 3G as the active interface even when WLAN is around, it has to override that default connection mapping policy 🙋♀️ an app-specific mapping policy can be set through a Microsoft API or provisioned by the Mobile Operator 🛠️ within the security model, an app can request a connection by interface type (WLAN, cellular), by minimum interface speed (x kbit/s, y Mbit/s), or by name (Access Point Name) 🦋
in dual-stack systems, Windows Mobile and Windows Phone 7 implement address selection rules per [WNDS-RFC3484] 🌐 an administrator can configure a policy table that overrides the default behaviour of the selection algorithms ⚙️ the policy table specifies precedence values and preferred source prefixes for destination prefixes (see [RFC3484], Section 2.1 for details) 💜 if the system hasn't been configured, the default policy table from [RFC3484] gets used 🌸
3.1.3. RIM BlackBerry ✨
okay so BlackBerry devices ([BLACKBERRY]) are lowkey flexible 💅 depending on how the network is set up, apps can use direct TCP/IP connectivity or different application proxies to get online over the wireless network. some wireless service providers give you an Internet gateway for direct TCP/IP access to the Internet, while others run a Wireless Application Protocol (WAP) gateway so HTTP connections can happen over WAP 🦋. you can also use the BlackBerry Enterprise Server ([BLACKBERRY]) as a network gateway! it's giving secure-gateway energy because it provides an HTTP and TCP/IP proxy service, so the app can manage HTTP and TCP/IP connections to the intranet or the Internet through it 🔐. an app that wants to reach the Internet can use the BlackBerry Internet Service, the wireless service provider's Internet gateway, or direct Internet connectivity over WLAN to handle its connections 🌸. picking the gateway is up to each app on its own. so one app can be built to always use the default Internet gateway, while another app can be built to use a preferred proxy when one is available 🎀
a BlackBerry device ([BLACKBERRY]) can be attached to multiple networks at the same time (wireless and wired) 🌈. in that case, several network interfaces can be tied to a single IP stack or to multiple IP stacks. the device, or the app, can pick the network interface in different ways. for example, the device can always map apps to the default network interface (or the default access network). when multiple IP stacks are tied to multiple interfaces, the app can choose the source address that matches the preferred interface. per-interface IP stacks also let you manage overlapping address spaces, which is so iconic 🧚 when several network interfaces get aggregated into one IP stack, the device matches each app with the most appropriate interface. that choice can be based on cost, type of service (ToS), and/or user preference 💜
the BlackBerry uses per-interface DNS configuration, so apps bound to a specific interface use the DNS settings for that interface 🍓
3.1.4. Google Android
okay Android is built on a Linux kernel, so in lots of situations it acts like a Linux device, as described in Section 3.2.2 🐧. like Linux, Android can manage multiple routing tables and relies on policy-based routing together with packet-filtering capabilities (see Section 3.2.2.1 for details). that setup can be used to deal with the complicated routing problems you get from multiple interfaces, like address space overlapping 🧩
for incoming packets, Android implements the weak host model [RFC1122] on both IPv4 and IPv6. however, Android can also be configured to support the strong host model 💅
DNS configuration is a little different 👀. Android doesn't list DNS servers in the file /etc/resolv.conf, which is what Linux uses. but like Linux, DNS configuration is node-scoped, even though it can rely on the DHCP client. for example, the udhcp client [UDHCP], which is also available for Linux, can be used on Android. every time the host gets new configuration data from a DHCP server, no matter which interface it came in on, the DHCP client overwrites the global configuration data with the most recent information it received 🌸
the big difference between Linux and Android is address selection 🫶. Android versions before 2.2 simply prefer IPv6 connectivity over IPv4. but it's worth noting that, at the time of writing, IPv6 is only available on WiFi and virtual interfaces, not on the cellular interface (unless you have IPv6 in IPv4 encapsulation). Android 2.2 got updated with [ANDROID-RFC3484], which implements some of the address selection rules defined in [RFC3484]. all [RFC3484] rules are supported, except rule 3 (avoid deprecated addresses), rule 4 (prefer home addresses), and rule 7 (prefer native transport). also, rule 9 (use longest matching prefix) has been modified so it does not sort IPv4 addresses 🔥
the Android reference documentation covers the android.net package [ANDROID] and the ConnectivityManager class ✨. apps can use it to ask for the first hop to a specified destination address via a specified network interface (Third Generation Partnership Project (3GPP) or WLAN). apps also ask the connection manager for permission to start using a network feature. the connection manager keeps an eye on changes in network connectivity and tries to fail over to another network if connectivity to an active network is lost. when connectivity changes, apps get notified 🔔. apps can also ask for info about all network interfaces, including their availability, type, and other details 💖
3.1.5. Qualcomm Brew
this section is about how multiple-interface support works in Advanced Mobile Station Software (AMSS), which comes with Brew OS for all Qualcomm chipsets (for example, Mobile Station Modem (MSM), Snapdragon, etc.) 📱. AMSS is a low-level connectivity platform, and manufacturers can build on top of it to give apps the connectivity they need 🛠️. how AMSS, the operating system, and the apps interact isn't one-size-fits-all; it depends on the design the manufacturer picks. the Mobile OS can let an app call AMSS directly (via API), or it can provide its own connection manager that asks AMSS for connectivity based on what the apps need 🦋. how the OS connection manager and the apps interact depends on the OS 🌈
AMSS supports a concept called netpolicy, which lets each app specify the type of network connectivity it wants 💅. the netpolicy holds things like access technology, IP version type, and network profile. access technology can be one specific technology, like CDMA or WLAN, or a group of technologies, like ANY_Cellular or ANY_Wireless. IP version can be IPv4, IPv6, or Default. the network profile identifies a type of network domain or service within a certain network technology, like a 3GPP APN or a Mobile IP Home Agent. it also holds all the mandatory parameters needed to connect to that domain, such as authentication credentials, plus optional stuff like Quality of Service (QoS) attributes. the network profile is technology-specific, so the set of parameters can vary between technologies 🧚
two models of network usage are supported 👑:
- Apps that need network connectivity specify a suitable netpolicy to select the network they want. the netpolicy may match one or more network interfaces. the AMSS system selection module picks the best interface out of the ones that match the netpolicy, based on criteria such as cost, speed, or other provisioned rules. the app explicitly starts the selected network interface, and as a result the app also gets bound to that interface. all outbound packets from this app are always routed over this bound interface, using the interface's source address 🎀
- Apps can rely on a separate connection manager to control (for example, start/stop) the network interface. in this model, apps aren't necessarily bound to any one interface. all outbound packets from these apps are routed on one of the interfaces that matches their netpolicy. the routing decision is made for each packet individually, and it selects the best interface based on the criteria above and the destination address. the source address is always assigned to the interface used to transmit the packet 🌸
all routing and interface selection decisions are based on the netpolicy, not just the destination address, to avoid the issue of overlapping private IPv4 addresses 🙈. this also lets multiple interfaces be configured with the same IP address, for example to handle certain tunneling scenarios. apps that don't specify a netpolicy get routed by AMSS to the best possible interface using the default netpolicy. the default netpolicy could be pre-defined or provisioned by the administrator or operator. so the default interface can vary from device to device, and it also depends on which networks are available at any given time 🍓
AMSS lets each interface have its own set of DNS configuration parameters (for example, a list of DNS servers, domain names, etc.) 💜. the interface chosen for a DNS resolution is the one the app making the DNS query is bound to. apps can also specify a different netpolicy as part of the DNS request to select another interface for DNS resolution. either way, all DNS queries are sent only over the selected interface, using that interface's DNS configuration. DNS resolution is first attempted with the primary server configured on the interface. if no response comes back, the queries go to all the other servers configured on the interface, one after another, using a backoff mechanism ⏳
3.1.6. Leadcore Technology Arena
Arena is a mobile OS based on Linux, and it has a connection manager described in [MIF-ARENA] and [MIF-REQS] 🌟. the Arena connection manager gives apps a way to register their connectivity requirements. it can then choose an interface that matches what the app needs while weighing other factors like availability, cost, and stability. the connection manager can also handle multiple-interface issues, such as connection sharing 🫶
3.2. Desktop Operating Systems
multiple-interface issues also show up on desktops 🖥️, in cases where a desktop host has multiple (logical or physical) interfaces connected to networks with different reachability properties. for example, one interface might be connected to the global Internet while another is connected to a corporate VPN 🔒
3.2.1. Microsoft Windows
the multiple-interface functionality currently in Microsoft Windows operating systems is covered in more detail in [MULTIHOMING] 🪟
3.2.1.1. First-Hop Selection
it's possible to configure default routers on more than one Windows interface, though it's not often desirable 🙃. in that setup, Windows uses the default route on the interface with the lowest routing metric (i.e., the fastest interface) ⚡. if multiple interfaces share the same metric, the behavior depends on which version of Windows is in use. before Windows Vista, the packet would be routed out of the first interface that was bound to the TCP/IP stack, which was the preferred interface. in Windows Vista, host-to-router load sharing [RFC4311] is used for both IPv4 and IPv6 💖
3.2.1.2. Outbound and Inbound Addresses
okay so, if the app doesn't pick a source address for an outgoing packet, Windows goes shopping through the addresses on its interfaces and picks one 🛍️ Windows uses [RFC3484] for source address selection in IPv6, and in Windows Vista it uses it for IPv4 too. Before Vista, IPv4 just grabbed the first address on the outgoing interface. very basic, lowkey iconic 💅
For incoming packets, Windows checks whether the destination address matches one of the addresses on its interfaces. Windows used the weak host model [RFC1122] for IPv4 in Windows 2000, Windows XP, and Windows Server 2003. The strong host model became the default for IPv4 in Windows Vista and Windows Server 2008, but the weak host model is still available through per-interface configuration 🔧 IPv6 has always used the strong host model, so it's been consistent this whole time 🫶
3.2.1.3. DNS Configuration
okay this one is a whole saga 🌀 Windows mostly leans on suffixes to sort out DNS resolution problems. Suffixes get used for four different jobs:
- DNS Suffix Search List (aka domain search list): a suffix is added to non-FQDNs (Fully Qualified Domain Names).
- Interface-specific suffix list: lets different DNS queries go to different DNS servers.
- Suffix to control Dynamic DNS Updates: decides which DNS server gets a dynamic update for a name with a certain suffix.
- Suffix in the Name Resolution Policy Table [NRPT]: helps identify a namespace that needs special handling (this only works on Windows 7 and its server counterpart, Windows Server 2008 R2 and later) 🎀
But this section only focuses on the interface-specific suffix list, since that's the only suffix usage in scope for this document ✨
DNS configuration can be host-wide or interface specific. Host-wide DNS config comes from static configuration or, in sites that use Active Directory, Microsoft's Group Policy. Interface-specific DNS config can come from static configuration or from DHCP.
The host-wide config has a primary DNS suffix for the local host, plus a list of suffixes that can be tacked onto names being queried. Before Windows Vista and Windows Server 2008, there was also a host-wide DNS server list, and it beat the per-interface DNS config 👑
The interface-specific config is made of an interface-specific suffix list and a list of DNS server IP addresses.
Windows uses a host-wide "effective" server list for each actual query, and that effective list can be different for different names 🧚 In the DNS server address list, the first server is the "primary" one, and everything else is secondary.
Here's the timing drama 😭 When a DNS query goes out in Windows, it's first sent to the primary DNS server on the preferred interface. If there's no response in one second, the query goes to the primary DNS servers on all interfaces under consideration. If there's still nothing for 2 more seconds, the DNS server sends the query to all of the DNS servers on the DNS server lists for all interfaces under consideration. If the host still doesn't get a response after 4 seconds, it sends to all of the servers again and waits 8 seconds for an answer 💀
3.2.2. Linux and BSD-Based Operating Systems
3.2.2.1. First-Hop Selection
Okay so, besides the two commonly used routing tables (the local and main routing tables), the kernel can support up to 252 extra routing tables, which you can add in the file /etc/iproute2/rt_tables 🍓 A routing table can hold any number of routes, and route selection is classically based on the packet's destination address. Linux also offers fancier route selection based on type of service, scope, and output interface. Since kernel version 2.2, Linux also supports policy-based routing using the multiple routing tables capability and a routing policy database. That database holds the routing rules the kernel uses. With policy-based routing, the source address, the ToS flags, the interface name, and an fwmark (a mark added to the data structure representing the packet) can all be used as route selectors 🦋
Policy-based routing can work alongside Linux packet-filtering tools, like the iptables tool, for example. In a multiple-interface setup, this tool can mark packets, meaning it assigns a number to the fwmark, so the routing rule gets picked based on the type of traffic. That mark can be assigned using things like protocol, source and/or destination addresses, port number, and so on 🌈
This kind of routing management framework lets you handle complicated stuff like overlapping address space. In that situation, the administrator can use packet marking and policy-based routing to pick the right interface 👑
3.2.2.2. Outbound and Inbound Addresses
By default, source address selection follows some basic rules. The application can pick the initial source address for an outbound packet using the bind() call. Without info from the application, the kernel picks the first address configured on the interface that's in the same subnet as the destination address or the next-hop router 💖
Linux also uses [RFC3484] for source address selection for IPv6 and dual-stack configurations. But the address-sorting rules from [RFC3484] aren't always good enough, so Linux lets the system administrator change the sorting on the fly. That's done with the /etc/gai.conf file 🎀
For incoming packets, Linux checks whether the destination address matches one of the addresses on its interfaces, and then processes the packet according to the configured host model. By default, Linux uses the weak host model [RFC1122] on both IPv4 and IPv6. But Linux can also be configured to use the strong host model ✨
3.2.2.3. DNS Configuration
Most BSD and Linux distros rely on their DHCP client to handle interface-specific info (like an IP address and netmask) and a set of system-wide config (like a DNS server list, an NTP server list, and default routes). Users of these OSes can pick any DHCP client that's available for their platform, with an OS default. This section talks about how several DHCP clients behave when used with Linux and BSD distros 🧚
The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with specific instructions for each interface. But every time the host gets new config data from a DHCP server, no matter which interface it came in on, the DHCP client rewrites the global config data, like the default routes and the DNS server list (in /etc/resolv.conf), with the newest info. So the last configured interface always becomes the primary one 😭 The ISC DHCPv6 client acts similarly. However, OpenBSD has two mechanisms that stop the config a user set manually from getting overwritten:
- OPTION MODIFIERS (default, supersede, prepend, and append): this mechanism lets the user override DHCP options. For example, the supersede statement defines, for some options, the values the client should always use instead of any value the server supplies.
- resolv.conf.tail: this lets the user append anything to the
resolv.conffile that the DHCP client creates.
The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the ISC client. It replaces the DNS server list in /etc/resolv.conf and the default routes every time new DHCP info comes in on any interface. However, the -R flag can be used to tell the client not to replace the DNS servers in /etc/resolv.conf. Hmm, but this flag is a global flag for the DHCP server, so it applies to every interface. When dhcpd gets called with the -R flag, the DNS servers are never replaced 🙈
The pump client [PUMP] also acts like the ISC client. It replaces the DNS servers in /etc/resolv.conf and the default routes every time new DHCP info comes in on any interface. However, the nodns and nogateway options can be set on a per-interface basis, so the user can choose which interface is used to get the global config info 🦋
The udhcp client [UDHCP] shows up a lot on embedded platforms based on busybox. It acts like the ISC client too: it rewrites default routes and the DNS server list every time new DHCP info arrives 🍓
Red Hat-based distros, like Red Hat, Centos, and Fedora, have a per-interface config option (PEERDNS) that says the DNS server list shouldn't get updated based on config received on that interface 🌸
Most configurable DHCP clients can be set to define a primary interface, and only that interface is used for the global config data. But this is limited, since a mobile host might not always have the same set of interfaces available. Connection managers may help in this situation 📱
Some distros also come with a connection manager. But most connection managers are basically a GUI on top of the DHCP client, so they don't change the functionality described above 💅
4. Acknowledgements
The authors of this document would like to thank the following people for their input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien Laganier, and Steinar H. Gunderson 🫶
5. Security Considerations
🚨 This one's important, bestie. This document describes current operating system implementations and how they handle the issues raised in the MIF problem statement. It's possible that the currently implemented mechanisms described in this document may affect the security of the systems described. This document only reports on current practice. It does not try to analyze the security properties (or any other architectural properties) of the currently implemented mechanisms. So please don't take this as a security audit 🔐
6. Contributors
The following people contributed most of the per-operating system information found in this document 🌟
- Marc Blanchet, Viagenie
- Hua Chen, Leadcore Technology, Ltd.
- Yan Zhang, Leadcore Technology, Ltd.
- Shunan Fan, Huawei Technology
- Jian Yang, Huawei Technology
- Gabriel Montenegro, Microsoft Corporation
- Shyam Seshadri, Microsoft Corporation
- Dave Thaler, Microsoft Corporation
- Kevin Chin, Microsoft Corporation
- Teemu Savolainen, Nokia
- Tao Sun, China Mobile
- George Tsirtsis, Qualcomm
- David Freyermuth, France Telecom
- Aurelien Collet, Altran
- Giyeong Son, RIM
7. References
7.1. Normative References
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418,
November 2011.7.2. Informative References 📚✨
okay bestie, these are the extra-credit reads 🤓 not required to understand the spec, but they're the receipts for how real OSes and vendors handled multi-interface stuff. the Windows Mobile, Android, and BlackBerry docs are giving history lesson vibes 💅
[ANDROID] Google Inc., "Android developers: package android.net",
<http://developer.android.com/reference/android/net/
ConnectivityManager.html>.
[ANDROID-RFC3484]
Gunderson, S., "RFC 3484 support for Android", 2010,
<http://gitorious.org/0xdroid/bionic/commit/
9ab75d4cc803e91b7f1b656ffbe2ad32c52a86f9>.
[BLACKBERRY] Research In Motion Limited, "BlackBerry Java
Development Environment - Fundamentals Guide: Wireless
gateways", <http://na.blackberry.com/eng/
deliverables/5827/Wireless_gateways_447132_11.jsp>.
[ISCDHCP] Internet Software Consortium, "ISC DHCP",
<http://www.isc.org/software/dhcp>.
[MIF-ARENA] Zhang, Y., Sun, T., and H. Chen, "Multi-interface
Network Connection Manager in Arena Platform", Work
in Progress, February 2009.
[MIF-REQS] Yang, J., Sun, T., and S. Fan, "Multi-interface
Connection Manager Implementation and Requirements",
Work in Progress, March 2009.
[MULTIHOMING] Montenegro, G., Thaler, D., and S. Seshadri, "Multiple
Interfaces on Windows", Work in Progress, March 2009.
[NRPT] Davies, J., "Name Resolution Policy Table",
February 2010, <http://technet.microsoft.com/en-
us/magazine/ff394369.aspx>.
[OPENBSDDHCLIENT]
OpenBSD, "OpenBSD dhclient", <http://www.openbsd.org/>.
[PHYSTECHDHCPC]
Phystech, "dhcpcd",
<http://www.phystech.com/download/dhcpcd.html>.
[PUMP] Red Hat, "PUMP", 2009, <http://redhat.com>.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
Sharing", RFC 4311, November 2005.
[S60] Nokia Corporation, "S60 Platform: IP Bearer
Management", 2007, <http://www.forum.nokia.com/info/
sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/
S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html>.
[UDHCP] Busybox, "uDHCP",
<http://busybox.net/downloads/BusyBox.html>.
[WINDOWSMOBILE]
Microsoft Corporation, "SDK Documentation for Windows
Mobile-Based Smartphones: Connection Manager", 2005,
<http://msdn.microsoft.com/en-us/library/
aa457829.aspx>.
[WNDS-RFC3484]
Microsoft Corporation, "SDK Documentation for Windows
Mobile-Based Smartphones: Default Address Selection for
IPv6", April 2010, <http://msdn.microsoft.com/en-us/
library/aa925716.aspx>.Authors' Addresses 🎀
and that's the whole tea ☕🦋 here's who wrote it, and how to reach them 💌
Margaret Wasserman
Painless Security, LLC
356 Abbott Street
North Andover, MA 01845
USA
Phone: +1 781 405-7464
EMail: mrw@painless-security.com
URI: http://www.painless-security.com
Pierrick Seite
France Telecom - Orange
4, rue du clos courtel BP 91226
Cesson-Sevigne 35512
France
EMail: pierrick.seite@orange.comthe end, babes 🌈💖 you made it through all of RFC 6419 and honestly? iconic behaviour 👑😭
📦 where this page comes from
- ietf: rfc6419 2011-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms