RFC 4584
Extension to Sockets API for Mobile IPv6
RFC 4584: Extension to Sockets API for Mobile IPv6 🦋
Okay bestie, let's get into RFC 4584 💖 It's an Informational doc, so it's giving "here's some good info" and not an Internet standard ✨. It came out of the Network Working Group, written by S. Chakrabarti and E. Nordmark at Sun Microsystems, and it's dated July 2006. The title block doesn't say it obsoletes or updates anything, so it's its own main character 💅
Status of This Memo 🫶
This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌸
Copyright Notice 🌈
Copyright (C) The Internet Society (2006).
Abstract 🔥
This doc describes data structures and API support for Mobile IPv6 as an extension to the Advanced Socket API for IPv6 🎀
Just like the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document gives that same level of access for Mobile IPv6 components 🧚 It specifies a mechanism for applications to retrieve and set information for Mobility Header messages, Home Address destination options, and Routing Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications.
Table of Contents 📋
1. Introduction ....................................................3
2. Applicability ...................................................4
3. Overview ........................................................5
4. Common Structures and Definitions ...............................6
4.1. The Mobility Header Data Structures ........................6
4.1.1. The ip6_mh Structure ................................6
4.1.2. Binding Refresh Request Mobility Message ............7
4.1.3. Home Address Test Init (HoTI) Message ...............7
4.1.4. Care-of Address Test Init (CoTI) Message ............7
4.1.5. Home Address Test (HOT) Message .....................8
4.1.6. Care Of Address Test (COT) Message ..................8
4.1.7. Binding Update Mobility Message .....................8
4.1.8. Binding Acknowledgement Mobility Message ............9
4.1.9. Binding Error Mobility Message ......................9
4.1.10. Mobility Option TLV data structure .................9
4.1.11. Mobility Option Data Structures ...................10
4.1.11.1. Binding Refresh Advice ...................10
4.1.11.2. Alternate Care-of Address ................10
4.1.11.3. Nonce Indices ............................10
4.1.11.4. Binding Authorization Data ...............10
4.2. Mobility Header Constants .................................10
4.3. IPv6 Home Address Destination Option ......................12
4.4. Type 2 Routing Header .....................................12
4.5. New ICMP Messages for Mobile IPv6 .........................13
4.6. IPv6 Neighbor Discovery Changes ...........................14
5. Access to Home Address Destination Option and Routing Headers ..15
5.1. Routing Header Access Functions ...........................17
5.2. Content of Type 2 Routing Header ..........................18
5.3. Order of Extension Headers for Home Address
Destination Options .......................................19
5.4. Home Address Destination Option Access Functions ..........20
5.5. Content of Home Address Destination Option ................20
6. Mobility Protocol Headers ......................................21
6.1. Receiving and Sending Mobility Header Messages ............21
7. Protocols File .................................................22
8. IPv4-Mapped IPv6 Addresses .....................................23
9. Security Considerations ........................................23
10. IANA Considerations ...........................................23
11. Acknowledgements ..............................................23
12. References ....................................................24
12.1. Normative References .....................................24
12.2. Informative References ...................................241. Introduction ✨
Mobility Support in IPv6 [2] defines a new Mobility Protocol header, a Home Address destination option and a new Routing Header type. It's expected that Mobile IPv6 user-level implementations and some special applications will need to access and process these IPv6 extension headers. This document is an extension to the existing Advanced Sockets API document [1], so it addresses the Advanced IPv6 Sockets API for these new protocol elements defined by Mobile IPv6 💅
The applicability of this API mainly targets user-level applications. However, it has also been shown to be useful within some Mobile IPv6 implementations, for instance where part of the Mobile IPv6 protocol is implemented at user-level and part in the kernel. It's up to any such implementations to architect which part of the Mobile IPv6 and IP Security (IPSec) packet processing should be done at the user-level, in order to meet the design needs of the particular platform and operating system 🧚
The target user-level applications for this socket API are believed to be debugging and diagnostic applications, plus some policy applications that would like to receive copies of protocol information at the application layer 🔍
The packet information and access to the extension headers (Routing header and Destination options) are specified using the "ancillary data" fields that were added to the 4.3BSD Reno sockets API in 1990. Why? Because these ancillary data fields are part of the Posix.1g standard and should therefore be adopted by most vendors 🌸 This document is consistent with Advanced Sockets API for IPv6 [1] in structure definitions, header files, and function definitions. So the implementors of this API document are assumed to be familiar with the data structures, data sending and receiving procedures, and the IPv6 extension header access functions described in the Advanced Sockets API for IPv6 [1] 🎀
Non-goals
This document does not address application access to either the Authentication Header or the Encapsulating Security Payload header. It also does not address any API that might be necessary for Mobile Network [4] specific needs. Furthermore, note that this API document excludes discussion on application-level API. It assumes that address selection socket API [5] takes care of selection of care-of address or home address as the source address by the application, when source address selection is required due to the nature of the application 🙈
Providing mobility "awareness" to applications, such as applications' being able to tell whether the host is at home or not, is out of scope for this API 🚫
2. Applicability 🎀
This API document can be applied in the following cases:
- User-level debugging and monitoring tools: This socket API is useful for accessing Mobility Headers, Home Address destination options and Type 2 Routing Headers. For example,
mh-pingmight be a monitoring tool that can process mobility headers on the receiving side to check binding status 👀 - Partial user-level implementation of Mobile IPv6: We assume that some implementations may choose to do the Mobility header processing at user level. In that case, this document recommends implementing at least the handling of Home Address destination options and Type 2 Routing Header in the main IP processing paths in the kernel. The API can then be used to send and receive the Mobility Header packets used for Mobile IPv6 signaling 🧠
- Complete header processing at the kernel-level: Many implementations of Mobile IPv6 [2] perform processing of Home Address destination options, Type 2 Routing Headers, and Mobility headers at the kernel level. However, the kernel keeps a copy of the received extension headers and passes them up to the API, which is used by the user-level applications purely for monitoring and debugging Mobile IPv6 packets 🪄
On an IPv6 host that does not implement Mobile IPv6, the IPv6 specification [3] requires that packets with the Home Address option or Type 2 Routing Header (where segments left is non-zero) be dropped on receipt. This means it's not possible to implement Mobile IPv6 as an application on such a system 😭 So on such a system, the applicability of this API is limited to the first case above, enabling debugging and monitoring applications (such as tcpdump) to parse and interpret Mobile IPv6 packets 💜
3. Overview 🧚
This document can be divided into the following parts:
- Constants and structures: Definitions of constants and structures for C programs that capture the Mobile IPv6 packet formats on the wire. A common definition of these is useful at least for packet snooping applications. This is captured in Section 4. In addition, Section 4 also defines data structures for Home Address destination option, Type 2 Routing Header, and new ICMPv6 messages related to Mobile IPv6 🌷
- Using the Advanced API: Notes on how to use the IPv6 Advanced API to access Home Address options and Type 2 Routing Headers. This is captured in Section 5 🦋
- Observing MH packets: Notes on how user-level applications can observe MH (Mobility Header) packets using raw sockets (in Section 6). The IPv6 RAW socket interface described in this document allows applications to receive MH packets whether or not the system's MH processing takes place in the "kernel" or at the "user space" 👑
- A protocol name: A name is suggested for IPv6 Mobility Header protocol in
/etc/protocols(in Section 7) 🍓
All examples in this document omit error checking in favor of brevity, as it is following the same style as the Advanced Socket API [1] 💅
Note that many of the functions and socket options defined in this document may have error returns that are not defined in this document 🙈
Data types in this document follow the Posix.1g format: intN_t means a signed integer of exactly N bits (e.g., int16_t), and uintN_t means an unsigned integer of exactly N bits (e.g., uint32_t) 🔥
Once the API specification becomes mature and is deployed, it may be formally standardized by a more appropriate body, as has been done with the Basic API [6]. However, since this specification largely builds upon the Advanced Socket API [1], such standardization would make sense only if the Advanced Socket API [1] were also standardized 🌈
Now for the key words, the ones that carry real weight. 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 RFC 2119 ⭐
4. Common Structures and Definitions ✨
okay so this section is where the structs live 💖 the big goal is to make the compiler lay out each data structure the same way the packet looks on the wire, so the bytes line up 🎀 ngl though, ANSI-C doesn't really promise anything about size or alignment, so it's kinda vibes-based 💀
we're assuming the Advanced Socket API [1] hands up the real packet content (the wire format) in the buffer and in the ancillary data objects 🧚 so if your system's ANSI-C compiler can't lay these structures out to match the wire formats in RFC 3775 [2], then the structures from this API just can't be supported there 😭
everything below is in network byte order, so your app has to do the byte order conversion (ntohs(), etc) whenever it's needed 🫶
the structs and constants below come along when you include the (new) header file <netinet/ip6mh.h> 🦋
4.1. The Mobility Header Data Structures
4.1.1. The ip6_mh Structure
the following struct shows up once you include <netinet/ip6mh.h> 💅 this is the fixed part of the Mobility Header. different Mobility message types are defined in Mobile IPv6 [2] ✨ for portability and alignment reasons, each mobility message type includes the mobility header fields directly instead of embedding the ip6_mh struct, and then adds its own message-specific fields after them 🎀
struct ip6_mh {
uint8_t ip6mh_proto; /* NO_NXTHDR by default */
uint8_t ip6mh_hdrlen; /* Header Len in unit of 8 Octets
excluding the first 8 Octets */
uint8_t ip6mh_type; /* Type of Mobility Header */
uint8_t ip6mh_reserved; /* Reserved */
uint16_t ip6mh_cksum; /* Mobility Header Checksum */
/* Followed by type specific messages */
};4.1.2. Binding Refresh Request Mobility Message
struct ip6_mh_binding_request {
uint8_t ip6mhbr_proto;
uint8_t ip6mhbr_hdrlen;
uint8_t ip6mhbr_type;
uint8_t ip6mhbr_reserved;
uint16_t ip6mhbr_cksum;
uint16_t ip6mhbr_reserved2;
/* Followed by optional Mobility Options */
};4.1.3. Home Address Test Init (HoTI) Message
struct ip6_mh_home_test_init {
uint8_t ip6mhhti_proto;
uint8_t ip6mhhti_hdrlen;
uint8_t ip6mhhti_type;
uint8_t ip6mhhti_reserved;
uint16_t ip6mhhti_cksum;
uint16_t ip6mhhti_reserved2;
uint32_t ip6mhhti_cookie[2]; /* 64 bit Cookie by MN */
/* Followed by optional Mobility Options */
};4.1.4. Care-of Address Test Init (CoTI) Message
struct ip6_mh_careof_test_init {
uint8_t ip6mhcti_proto;
uint8_t ip6mhcti_hdrlen;
uint8_t ip6mhcti_type;
uint8_t ip6mhcti_reserved;
uint16_t ip6mhcti_cksum;
uint16_t ip6mhcti_reserved2;
uint32_t ip6mhcti_cookie[2]; /* 64 bit Cookie by MN */
/* Followed by optional Mobility Options */
};4.1.5. Home Address Test (HOT) Message
struct ip6_mh_home_test {
uint8_t ip6mhht_proto;
uint8_t ip6mhht_hdrlen;
uint8_t ip6mhht_type;
uint8_t ip6mhht_reserved;
uint16_t ip6mhht_cksum;
uint16_t ip6mhht_nonce_index;
uint32_t ip6mhht_cookie[2]; /* Cookie from HOTI msg */
uint32_t ip6mhht_keygen[2]; /* 64 Bit Key by CN */
/* Followed by optional Mobility Options */
};4.1.6. Care Of Address Test (COT) Message
struct ip6_mh_careof_test {
uint8_t ip6mhct_proto;
uint8_t ip6mhct_hdrlen;
uint8_t ip6mhct_type;
uint8_t ip6mhct_reserved;
uint16_t ip6mhct_cksum;
uint16_t ip6mhct_nonce_index;
uint32_t ip6mhct_cookie[2]; /* Cookie from COTI message */
uint32_t ip6mhct_keygen[2]; /* 64bit key by CN */
/* Followed by optional Mobility Options */
};4.1.7. Binding Update Mobility Message
struct ip6_mh_binding_update {
uint8_t ip6mhbu_proto;
uint8_t ip6mhbu_hdrlen;
uint8_t ip6mhbu_type;
uint8_t ip6mhbu_reserved;
uint16_t ip6mhbu_cksum;
uint16_t ip6mhbu_seqno; /* Sequence Number */
uint16_t ip6mhbu_flags;
uint16_t ip6mhbu_lifetime; /* Time in unit of 4 sec */
/* Followed by optional Mobility Options */
};
/* Binding Update Flags, in network byte-order */
#define IP6_MH_BU_ACK 0x8000 /* Request a binding ack */
#define IP6_MH_BU_HOME 0x4000 /* Home Registration */
#define IP6_MH_BU_LLOCAL 0x2000 /* Link-local compatibility */
#define IP6_MH_BU_KEYM 0x1000 /* Key management mobility */4.1.8. Binding Acknowledgement Mobility Message
struct ip6_mh_binding_ack {
uint8_t ip6mhba_proto;
uint8_t ip6mhba_hdrlen;
uint8_t ip6mhba_type;
uint8_t ip6mhba_reserved;
uint16_t ip6mhba_cksum;
uint8_t ip6mhba_status; /* Status code */
uint8_t ip6mhba_flags;
uint16_t ip6mhba_seqno;
uint16_t ip6mhba_lifetime;
/* Followed by optional Mobility Options */
};
/* Binding Acknowledgement Flags */
#define IP6_MH_BA_KEYM 0x80 /* Key management mobility */4.1.9. Binding Error Mobility Message
struct ip6_mh_binding_error {
uint8_t ip6mhbe_proto;
uint8_t ip6mhbe_hdrlen;
uint8_t ip6mhbe_type;
uint8_t ip6mhbe_reserved;
uint16_t ip6mhbe_cksum;
uint8_t ip6mhbe_status; /* Error Status */
uint8_t ip6mhbe_reserved2;
struct in6_addr ip6mhbe_homeaddr;
/* Followed by optional Mobility Options */
};4.1.10. Mobility Option TLV data structure
struct ip6_mh_opt {
uint8_t ip6mhopt_type; /* Option Type */
uint8_t ip6mhopt_len; /* Option Length */
/* Followed by variable length Option Data in bytes */
};4.1.11. Mobility Option Data Structures
4.1.11.1. Binding Refresh Advice
struct ip6_mh_opt_refresh_advice {
uint8_t ip6mora_type;
uint8_t ip6mora_len;
uint16_t ip6mora_interval; /* Refresh interval in 4 sec */
};4.1.11.2. Alternate Care-of Address
struct ip6_mh_opt_altcoa {
uint8_t ip6moa_type;
uint8_t ip6moa_len;
struct in6_addr ip6moa_addr; /* Alternate CoA */
};4.1.11.3. Nonce Indices
struct ip6_mh_opt_nonce_index {
uint8_t ip6moni_type;
uint8_t ip6moni_len;
uint16_t ip6moni_home_nonce;
uint16_t ip6moni_coa_nonce;
};4.1.11.4. Binding Authorization Data
struct ip6_mh_opt_auth_data {
uint8_t ip6moad_type;
uint8_t ip6moad_len;
uint8_t ip6moad_data[12];
};4.2. Mobility Header Constants
here are the constants you'll need 🎀 first up, the IPv6 Next Header value for Mobility 🌸
IPv6 Next Header Value for Mobility:
<netinet/in.h>
#define IPPROTO_MH 135 /* IPv6 Mobility Header: IANA */
Mobility Header Message Types:
<netinet/ip6mh.h>
#define IP6_MH_TYPE_BRR 0 /* Binding Refresh Request */
#define IP6_MH_TYPE_HOTI 1 /* HOTI Message */
#define IP6_MH_TYPE_COTI 2 /* COTI Message */
#define IP6_MH_TYPE_HOT 3 /* HOT Message */
#define IP6_MH_TYPE_COT 4 /* COT Message */
#define IP6_MH_TYPE_BU 5 /* Binding Update */
#define IP6_MH_TYPE_BACK 6 /* Binding ACK */
#define IP6_MH_TYPE_BERROR 7 /* Binding Error */next up are the Mobility Header message option types 🦋
Mobility Header Message Option Types:
<netinet/ip6mh.h>
#define IP6_MHOPT_PAD1 0x00 /* PAD1 */
#define IP6_MHOPT_PADN 0x01 /* PADN */
#define IP6_MHOPT_BREFRESH 0x02 /* Binding Refresh */
#define IP6_MHOPT_ALTCOA 0x03 /* Alternate COA */
#define IP6_MHOPT_NONCEID 0x04 /* Nonce Index */
#define IP6_MHOPT_BAUTH 0x05 /* Binding Auth Data */then the status values that come with the Mobility Binding Acknowledgement 🔥
Status values accompanied with Mobility Binding Acknowledgement:
<netinet/ip6mh.h>
#define IP6_MH_BAS_ACCEPTED 0 /* BU accepted */
#define IP6_MH_BAS_PRFX_DISCOV 1 /* Accepted, but prefix
discovery Required */
#define IP6_MH_BAS_UNSPECIFIED 128 /* Reason unspecified */
#define IP6_MH_BAS_PROHIBIT 129 /* Administratively
prohibited */
#define IP6_MH_BAS_INSUFFICIENT 130 /* Insufficient
resources */
#define IP6_MH_BAS_HA_NOT_SUPPORTED 131 /* HA registration not
supported */
#define IP6_MH_BAS_NOT_HOME_SUBNET 132 /* Not Home subnet */
#define IP6_MH_BAS_NOT_HA 133 /* Not HA for this
mobile node */
#define IP6_MH_BAS_DAD_FAILED 134 /* DAD failed */
#define IP6_MH_BAS_SEQNO_BAD 135 /* Sequence number out
of range */
#define IP6_MH_BAS_HOME_NI_EXPIRED 136 /* Expired Home nonce
index */
#define IP6_MH_BAS_COA_NI_EXPIRED 137 /* Expired Care-of
nonce index */
#define IP6_MH_BAS_NI_EXPIRED 138 /* Expired Nonce
Indices */
#define IP6_MH_BAS_REG_NOT_ALLOWED 139 /* Registration type
change disallowed */and last but not least, the status values for the Binding Error mobility messages 😭
Status values for the Binding Error mobility messages:
<netinet/ip6mh.h>
#define IP6_MH_BES_UNKNOWN_HAO 1 /* Unknown binding for HOA */
#define IP6_MH_BES_UNKNOWN_MH 2 /* Unknown MH Type */4.3. IPv6 Home Address Destination Option
okay this one's a little finicky 🙈 because of alignment issues in the compiler, and the alignment requirements for this option, the included IPv6 address must be specified as an array of 16 octets 🧚
<netinet/ip6.h>
/* Home Address Destination Option */
struct ip6_opt_home_address {
uint8_t ip6oha_type;
uint8_t ip6oha_len;
uint8_t ip6oha_addr[16]; /* Home Address */
};the option type definition is ✨
Option Type Definition:
#define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */4.4. Type 2 Routing Header
last one for this part 🌈 here's the Type 2 Routing header struct for Mobile IPv6 💜
<netinet/ip6.h>
/* Type 2 Routing header for Mobile IPv6 */
struct ip6_rthdr2 {
uint8_t ip6r2_nxt; /* next header */
uint8_t ip6r2_len; /* length : always 2 */
uint8_t ip6r2_type; /* always 2 */
uint8_t ip6r2_segleft; /* segments left: always 1 */
uint32_t ip6r2_reserved; /* reserved field */
struct in6_addr ip6r2_homeaddr; /* Home Address */
};4.5. New ICMP Messages for Mobile IPv6 🦋
okay so the ICMP message types and definitions for Mobile IPv6 live in <netinet/icmp6.h> 🎀 bookmark it, bestie
#define MIP6_HA_DISCOVERY_REQUEST 144
#define MIP6_HA_DISCOVERY_REPLY 145
#define MIP6_PREFIX_SOLICIT 146
#define MIP6_PREFIX_ADVERT 147the structs below are for the ICMP message types from Sections 6.5 through 6.8 in the base Mobile IPv6 [2] spec ✨ they're literally the building blocks for all of this 💅
struct mip6_dhaad_req { /* Dynamic HA Address Discovery */
struct icmp6_hdr mip6_dhreq_hdr;
};
#define mip6_dhreq_type mip6_dhreq_hdr.icmp6_type
#define mip6_dhreq_code mip6_dhreq_hdr.icmp6_code
#define mip6_dhreq_cksum mip6_dhreq_hdr.icmp6_cksum
#define mip6_dhreq_id mip6_dhreq_hdr.icmp6_data16[0]
#define mip6_dhreq_reserved mip6_dhreq_hdr.icmp6_data16[1]
struct mip6_dhaad_rep { /* HA Address Discovery Reply */
struct icmp6_hdr mip6_dhrep_hdr;
/* Followed by Home Agent IPv6 addresses */
};
#define mip6_dhrep_type mip6_dhrep_hdr.icmp6_type
#define mip6_dhrep_code mip6_dhrep_hdr.icmp6_code
#define mip6_dhrep_cksum mip6_dhrep_hdr.icmp6_cksum
#define mip6_dhrep_id mip6_dhrep_hdr.icmp6_data16[0]
#define mip6_dhrep_reserved mip6_dhrep_hdr.icmp6_data16[1]
struct mip6_prefix_solicit { /* Mobile Prefix Solicitation */
struct icmp6_hdr mip6_ps_hdr;
};
#define mip6_ps_type mip6_ps_hdr.icmp6_type
#define mip6_ps_code mip6_ps_hdr.icmp6_code
#define mip6_ps_cksum mip6_ps_hdr.icmp6_cksum
#define mip6_ps_id mip6_ps_hdr.icmp6_data16[0]
#define mip6_ps_reserved mip6_ps_hdr.icmp6_data16[1]
struct mip6_prefix_advert { /* Mobile Prefix Advertisements */
struct icmp6_hdr mip6_pa_hdr;
/* Followed by one or more PI options */
};
#define mip6_pa_type mip6_pa_hdr.icmp6_type
#define mip6_pa_code mip6_pa_hdr.icmp6_code
#define mip6_pa_cksum mip6_pa_hdr.icmp6_cksum
#define mip6_pa_id mip6_pa_hdr.icmp6_data16[0]
#define mip6_pa_flags_reserved mip6_pa_hdr.icmp6_data16[1]
/* Mobile Prefix Advertisement Flags in network-byte order */
#define MIP6_PA_FLAG_MANAGED 0x8000
#define MIP6_PA_FLAG_OTHER 0x4000prefix options are defined in IPv6 Advanced Socket API [1] 🌸 the Mobile IPv6 Base spec [2] explains the modified behavior in the 'Modifications to IPv6 Neighbor Discovery' section 🧚 and the Prefix Options for Mobile IP are defined in the next section, so keep scrolling 🍓
4.6. IPv6 Neighbor Discovery Changes 💜
IPv6 Neighbor Discovery changes are also defined in <netinet/icmp6.h> ✨ it's giving consistency, no cap
New 'Home Agent' flag in router advertisement: #define
ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */
New Router flag with prefix information of the home agent:
#define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */As per the Mobile IPv6 specification [2], Section 7.2, a Home Agent MUST include at least one prefix option with the Router Address (R) bit set. Advanced Socket API [1] defines the data structure for the prefix option like this 🎀
struct nd_opt_prefix_info { /* prefix information */
uint8_t nd_opt_pi_type;
uint8_t nd_opt_pi_len;
uint8_t nd_opt_pi_prefix_len;
uint8_t nd_opt_pi_flags_reserved;
uint32_t nd_opt_pi_valid_time;
uint32_t nd_opt_pi_preferred_time;
uint32_t nd_opt_pi_reserved2;
struct in6_addr nd_opt_pi_prefix;
};the new advertisement interval option and home agent information options are defined in the Mobile IPv6 [2] base spec 🦋 they're the newcomers, so give them some love 🫶
struct nd_opt_adv_interval { /* Advertisement interval option */
uint8_t nd_opt_ai_type;
uint8_t nd_opt_ai_len;
uint16_t nd_opt_ai_reserved;
uint32_t nd_opt_ai_interval;
};the option types for the new Mobile IPv6 specific options are:
#define ND_OPT_ADV_INTERVAL 7 /* Adv Interval Option */
#define ND_OPT_HA_INFORMATION 8 /* HA Information option */
struct nd_opt_homeagent_info { /* Home Agent information */
uint8_t nd_opt_hai_type;
uint8_t nd_opt_hai_len;
uint16_t nd_opt_hai_reserved;
uint16_t nd_opt_hai_preference;
uint16_t nd_opt_hai_lifetime;
};5. Access to Home Address Destination Option and Routing Headers 🌈
okay so applications that need to reach the Home Address destination option and Type 2 Routing Header info can do it by setting the right setsockopt option and using ancillary data objects 💅 the order of extension headers is defined in Mobile IPv6 [2] for when an IPv6 packet with a Home Address Destination Option gets sent alongside other possible extension headers 👑 Section 5.3 breaks down the extension header order for when every possible case shows up ✨
this document does not recommend that the user-level program set the Home Address destination option or Type 2 Routing Header option 🙈 but, for clarity, it does define the order of extension headers 🧚 see Section 2 of this document for the appropriate way to send and receive Home Address destination options and Type 2 Routing Header extension headers 🎀
this document defines a new socket option, IPV6_MIPDSTOPTS, for sending Home Address destination options 🦋 to receive a Home Address destination option or Type 2 Route Header, applications have to call setsockopt() to turn on the matching flag, as described in IPv6 Advanced Socket API [1] (for brevity, error checking is not performed in the examples 🙈):
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS,
&on, sizeof(on));when any of these options are enabled, the matching data gets returned as control information by recvmsg(), as one or more ancillary data objects 🌸 receiving this info for TCP applications isn't defined in this document, so check Section 4.1 of Advanced Sockets API for IPv6 [1] if you need that 🍓
note that if the IP implementation on the host doesn't implement handling of Type 2 Routing Headers or Home Address options, then per RFC 2460 [3] the IP stack is required to drop the packet 💀 so receiving the Home Address destination option and Type 2 Routing Header at the application layer needs the respective extension headers implemented at the IP layer in the kernel, as defined in RFC3775 [2] 🔥
for receiving the Home Address destination option header, the Mobile IPv6 implementation SHOULD follow the initial processing rules of the Home Address destination option (Section 9.3.1 of Mobile IPv6 [2]) before passing the info up to the API level 🫶 this includes initial processing of IPSec authentication data in a packet when it exists 🔐 each Destination options header is returned as one ancillary data object, described by a cmsghdr structure with cmsg_level set to IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS ✨
for sending the Home Address destination option, ancillary data can be used to specify the option content for a single datagram 🦋 this only applies to datagram and raw sockets, not TCP sockets 🙅 the Advanced API [1] document restricts one IPV6_xxx ancillary data object for a particular extension header in the control buffer, so there's a single ancillary data object for the Home address destination option in an ancillary data buffer 💜 if multiple destination options are present, then the header order should follow Section 6.3 and 9.3.2 of the Mobile IPv6 [2] base specification 🧚
for TCP data packets with the Home Address destination option, the "sticky" option may be used for all transmitted packets 🌸 the application can remove the sticky Home Destination option header by calling setsockopt() for IPV6_MIPDSTOPTS with a zero option length 🍓
note that Section 2 of this document does not encourage setting the Home Address destination option at the user level 🙈 a Mobile IPv6 implementation should set and process the Home Address destination option and Routing Header Type 2 at the kernel level 👑 setting the Routing Header Type 2 and the Home Address destination option is described in this document for completeness and flexibility, in case there's a need to use them in the future 🎀
the following socket option parameters and cmsghdr fields may be used for sending (although not a recommended usage 💀):
opt level/ optname/ optval/
cmsg_level cmsg_type cmsg_data[]
------------ ------------ ------------------------
IPPROTO_IPV6 IPV6_MIPDSTOPTS ip6_dest structure
IPPROTO_IPV6 IPV6_RTHDR ip6_rthdr structuresome IPv6 implementations may support "sticky" options [1] for the IPv6 destination option for datagram and RAW sockets ✨
Behavior of Legacy IPv6 Socket Applications:
legacy IPv6 applications and implementations using the Advanced Socket API [1] mechanisms, upon receiving Home Address destination options or Routing headers (Type 2), will discard the packet as per Sections 4.2 and 4.4 of IPV6 Protocol [3] specification, respectively 😭 otherwise, they should properly handle the Home Address destination option and the Routing Header Type 2 specified in this document 🫶
5.1. Routing Header Access Functions ✨
okay so the IPv6 Protocol [3] only defines a Routing header for Type 0 💅 That means if you want to reach the Routing header Type 2 extension header, you MUST use type = 2 and segment = 1. 🎀 The following functions from Advanced API for IPv6 Sockets [1] already exist and work for Mobile IPv6 apps when you're sending or receiving Routing Header Type 2 headers:
For Sending:
size_t inet6_rth_space(int type, int segments);
void *inet6_rth_init(void *bp, int bp_len, int type, int segments);
int inet6_rth_add(void *bp, const struct in6_addr *addr);For Receiving:
int inet6_rth_segments(const void *bp);
struct in6_addr *inet6_rth_getaddr(const void *bp, int index);NOTE: Reversing operation is not possible using the Route Header Type 2 extension header. Thus, inet6_rth_reverse() is not used. 🙈
Full explanations and examples for poking at an IPv6 Routing Header are in the Advanced Sockets API for IPv6 [1] 📚 Section 7 of Advanced API for IPv6 Sockets [1] also says that several kinds of routing headers can show up as multiple ancillary data objects for the app (with cmsg_type set to IPV6_RTHDR). Right now there aren't any API functions that hand back the routing header type 🥲 but this document doesn't define a helper for it, because reading the Routing Header Type field is just as easy as reading the ip6r_segleft field. Here's an excerpt of a code sample that pulls out the type of a received routing header:
if (msg.msg_controllen != 0 &&
cmsgptr->cmsg_level == IPPROTO_IPV6 &&
cmsgptr->cmsg_type == IPV6_RTHDR) {
struct in6_addr *in6;
char asciiname[INET6_ADDRSTRLEN];
struct ip6_rthdr *rthdr;
int segments, route_type;
rthdr = (struct ip6_rthdr *)extptr;
segments = inet6_rth_segments(extptr);
printf("route (%d segments, %d left): ",
segments, rthdr->ip6r_segleft);
route_type = rthdr->ip6r_type;
if (route_type == 2) {
printf ("Routing header Type 2 present\n");
}
}5.2. Content of Type 2 Routing Header 🌸
It is recommended that no portable applications send Type 2 Routing Header ancillary data from the application layer 🙃 Plenty of implementations handle that down in the kernel, and they might not support the API for sending a Type 2 Routing Header anyway.
Mobile IPv6 [2] defines the Type 2 Routing Header so a packet can go straight from a correspondent to the mobile node's care-of address 🦋 The care-of address goes into the IPv6 Destination Address field. Once the packet gets to the care-of address, the mobile node pulls its home address out of the routing header, and that becomes the final destination address for the received IPv6 packet. The way that it all clicks together is so satisfying 😭
For user-level apps receiving a Type 2 Routing Header, inet6_rth_getaddr() gives back the care-of address or the on-the-wire destination address of the received packet. This matches the existing Routing header Type=0 processing for IPv6 [1] ✨
So on the receive side, the socket app will always get data packets at its original home address 💖 The implementations are responsible for processing the Type 2 Routing Header packet as per Mobile IPv6 RFC [2] before the Type 2 Routing Header information gets passed up to the Socket API.
If a pure IPv6 [3] system receives Routing Header Type 2 packets, it follows the process described in Section 4.4 of the IPv6 [3] base specification. 🧚
5.3. Order of Extension Headers for Home Address Destination Options 🍓
Section 6.3 of Mobile IPV6 [2] defines the extension header order for the Home address destination option 🗂️
Routing Header
Home Address Destination Option
Fragment Header
AH/ESP HeaderIPv6 [3] says the destination header can come either before the Routing header or after the AH/ESP header, as long as they're all present 👑
So when the Home Address destination option shows up with other extension headers, the order goes like this:
Hop-by-Hop Options header
Destination Options header
Routing header
Destination Options [Home Address Option]
Fragment header
Authentication header
Encapsulating Security Payload header
Destination Options header
upper-layer headerAny user-level implementation or app that sends the Home address destination option through ancillary data objects should follow the extension header order defined in this document when it uses IPV6_MIPDSTOPTS socket options 🔥
5.4. Home Address Destination Option Access Functions 🎀
The app must enable the IPV6_RECVDSTOPTS socket option to receive the Home Address destination option (error checking is left out of this example to keep things short) 🫶
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));Each Destination option header comes back as one ancillary data object, described by a cmsghdr structure, with cmsg_level set to IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS 💜
On the receiving side, the Home Address destination option gets further processed by calling the inet6_opt_next(), inet6_opt_find(), and inet6_opt_get_value() functions, as defined in Advanced API for IPv6 sockets [1] ✨
This document assumes portable Mobile IPv6 apps won't send a Home Address Destination Option from the application level 💅 The Mobile IPv6 implementation underneath handles sending the Home Address option and the routing header type 2 in the kernel. Some embedded software, though, does IPv6 packet processing and sending at the user level. Those implementations may choose to offer API support for sending a home-address option at the application layer. In that case, the Home Address destination options are usually built with the inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and inet6_opt_set_val() functions, described in Section 10 of the Advanced sockets API for IPv6 [1] 🧚
5.5. Content of Home Address Destination Option 💖
The received ancillary data object for the Home Address destination option SHOULD contain the care-of address of the mobile node 🥹 It's assumed that the initial processing of the Home Address destination option will check that the home address is valid, as described in Sections 6.3 and 9.5 of the Mobile IPv6 Specification [2], and swap the source address of the packet (COA) with the contents of the Home Address destination option. 🔄
Heads up: whether or not these new APIs get used, the sender's home address is still in the source address. That's what gets passed to the app through the socket-level functions recvfrom(), recvmsg(), accept(), and getpeername(). It's necessary for:
- maintaining consistency between simple user-level applications running between mobile nodes and the diagnostic applications on the home agent or correspondent node that use this API;
- obtaining the COA address of the mobile node when the Home Address destination option is used; and
- maintaining consistency of existing IPv6 Socket APIs and processing of the Home Address destination option.
If an implementation supports send-side Home Address destination API, then it must follow the same data content rule as Mobile IPv6 RFC [2] specifies for sending a home-address option 🧠 So the home-address option contains the home address, and the implementation uses the care-of address as the source address of the outgoing packet. If the implementation uses IPSec, then it should use the content of the Home Address destination option as the source address of the packet for the security association. Note that regular user applications must not set the home address destination option. 🚫
6. Mobility Protocol Headers 🦋
Mobile IPv6 [2] defines a new IPv6 protocol header to carry mobility messages between Mobile Nodes, Home Agents and Correspondent Nodes 🌈 These protocol headers carry Mobile IPv6 Binding messages as well as Return Routability [2] messages. Currently the specification [2] doesn't let transport packets piggyback along with the mobility messages. So the mobility protocol header can be accessed through an IPv6 RAW socket. An IPv6 RAW socket opened for protocol IPPROTO_MH should always be able to see all the MH (Mobility Header) packets 👀 Future apps might implement part of the Mobile IPv6 signal processing at the application level. Having a RAW socket interface could also let an app run the Return Routability protocol, or some other future authentication protocol involving the mobility header, at the user level 🔐
6.1. Receiving and Sending Mobility Header Messages 🎀
This specification recommends that the IPv6 RAW sockets mechanism send and receive Mobility Header (MH) packets 🫶 It works kind of like ICMPV6 processing, where the kernel passes a copy of the mobility header packet to the receiving socket. Depending on the implementation, the kernel may process the mobility header as well as passing it to the application. To follow the restriction in the Advanced Sockets API for IPv6 [1], applications should set the IPV6_CHECKSUM socket option with IPPROTO_MH protocol RAW Sockets 💅 A Mobile IPv6 implementation that supports the Mobile IPv6 API must implement Mobility Header API checksum calculations by default at the kernel for both incoming and outbound paths. A Mobile IPv6 implementation must not return an error on the IPV6_CHECKSUM socket option setting, even when that option is a NO-OP for that implementation because it verifies the checksum at the kernel level. The Mobility Header checksum procedure is described in the Mobile IPv6 Protocol [2] specification. And again, for application portability, it is recommended that applications set the IPV6_CHECKSUM socket option along with the RAW sockets for IPPROTO_MH protocol 🌸
Here's an example of a program that wants to send or receive a mobility header protocol (MH) packet. It opens a socket like this (error checking is skipped for brevity):
fd = socket(AF_INET6, SOCK_RAW, IPPROTO_MH);
int offset = 4;
setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset,
sizeof(offset));For example, if an implementation wants to handle HOTI/HOT and COTI/COT message processing, it can do that by using IPv6 RAW Sockets for IPPROTO_MH at the application layer 🧚 The same app may also set the IPV6_RECVDSTOPTS socket option to receive the Home Address destination option in a binding update [2] from the mobile node.
IPv6 RAW sockets are described in Section 3 of the IPv6 Advanced Socket API [1] specification 📚 All data sent and received via raw sockets must be in network byte order. The data structures defined in this document are in network byte order, and they're believed to be supported by most compilers to hold packet formats directly for transmission on the wire. 🧠
The usual send/recv functions for datagrams should be used with the Mobile IPv6 RAW sockets to send and receive data, respectively. 💜
7. Protocols File 🎀
okay so bestie, lots of hosts have this file called /etc/protocols 📖 and it's basically a little directory of the IP protocols and their numbers 🔢 apps get those numbers through the getprotoXXX() functions, which is so neat. 🦋
You should add this on top of what's already in Section 2.4 of the Advanced Sockets API for IPv6 [1] 💅 The new entry is for the Mobility Header (see http://www.iana.org/assignments/protocol-numbers 🌸):
ipv6-mh 135 # Mobility Protocol Header8. IPv4-Mapped IPv6 Addresses ✨
ngl this section is so important 🙈 All the socket options and ancillary data stuff in this document only applies to true IPv6 sockets 💜 You can make an IPv6 socket that actually sends and receives IPv4 packets by using IPv4-mapped IPv6 addresses, but how the options in this document map onto an IPv4 datagram is out of scope for this doc 🫶 This is consistent with Section 13 of the IPv6 Socket API [1], so we're all on the same page 📚
9. Security Considerations 💀
okay this one is SERIOUS bestie, so pay attention 😭🔥 Setting the Home Address Destination option and the Route Header Type 2 IPV6_RTHDR socket option might not be allowed at the application level, and the reason is to stop denial-of-service attacks or man-in-the-middle attacks from hackers 🙅♀️
Sending and receiving mobility header messages is possible with IPv6 RAW sockets 👀 So it's assumed that only privileged users can do this operation 👑
This API does NOT stop the existing threat of a hacker sending a bogus mobility header or other IPv6 packets that use the Home Address option and Type 2 Routing Header extensions. Be careful out there, babe 🚨
10. IANA Considerations 🌈
This document doesn't define a brand new protocol ✨ What it does do is use the Mobility Header Protocol for IPv6 to define an API for the /etc/protocols file, and the registry info lives at http://www.iana.org/assignments/protocol-numbers 🧚
11. Acknowledgements 🫶
Big thank-yous, bestie 💖 Thanks to Brian Haley for the thorough review and many helpful comments. Keiichi Shima, Alexandru Petrescu, Ryuji Wakikawa, Vijay Devarapalli, Jim Bound, Suvidh Mathur, Karen Nielsen, Mark Borst, Vladislav Yasevich, and other mobile-ip working group members gave super valuable input 🌸 Antti Tuominen suggested the routing header type function for this API document 🦋 During IESG review, Bill Fenner suggested accessing the routing header type directly so it stays consistent with RFC3542 🎀 A new socket option for the Home Address Destination Option was added per Bill Fenner's suggestion, for clarity of extension header orders 💅 And thanks to Thomas Narten and Jari Arkko for reviewing this document 🥰
12. References 📚
12.1. Normative References
[1] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
12.2. Informative References
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[5] Nordmark, E., "IPv6 Socket API for source address selection", Work in Progress, July 2005.
[6] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
Authors' Addresses 🌟
Samita Chakrabarti
EMail: samitac2@gmail.com
Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.comFull Copyright Statement ©
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔐
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💖
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🌷
That's the end of RFC 4584, bestie. You did it! 🌈👑
📦 where this page comes from
- ietf: rfc4584 2006-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms