RFC 6521
Home Agent-Assisted Route Optimization between Mobile IPv4 Networks
Pages: 53
Experimental
Experimental
Part 2 of 2 – Pages 23 to 53
4. Data Compression Schemes
This section defines the two compression formats used in Route Optimization Prefix Advertisement Extensions.4.1. Prefix Compression
Prefix compression is based on the idea that prefixes usually share common properties. The scheme is simple delta compression. In the prefix information advertisement (Section 5.5), the 'D' bit indicates whether receiving a "master" or a "delta" prefix. This, combined with the Prefix Length information, allows for compression and decompression of prefix information. If D = 0, what follows in the "Prefix" field are bits 1..n of the new master prefix, where n is PLen. This is rounded up to the nearest full octet. Thus, prefix lengths of /4 and /8 take 1 octet, /12 and /16 take 2 octets, /20 and /24 take 3 octets, and longer prefix lengths take a full 4 octets. If D = 1, what follows in the "Prefix" field are bits m..PLen of the prefix, where m is the first changed bit of the previous master prefix, with padding from the master prefix filling the field to a full octet. The maximum value of PLen - m is 8 (that is, the delta MUST fit into one octet). If this is not possible, a new master prefix has to be declared. If the prefixes are equal -- for example, in the case where the same prefix appears in multiple realms -- then one octet is still encoded, consisting completely of padding from the master prefix.
Determining the order of prefix transmission should be based on saving maximum space during transmission. An example of compression and transmitted data, where network prefixes 192.0.2.0/28, 192.0.2.64/26, and 192.0.2.128/25 are transmitted, is illustrated in Figure 1. Because of the padding to full octets, redundant information is also sent. The bit patterns being transmitted are as follows: =+= shows the prefix mask --- shows the master prefix for delta coded prefixes 192.0.2.0/28, D = 0 0 1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|0|0|0|0|0|0|0| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+ ^ ^ +---------------------------- encoded ------------------------------+ ^ ^ +-pad-+ 192.0.2.64/26, D = 1 0 1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-------------------------------------------------------------+-+-+-+-+ |1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|1|0|0|0|0|0|0| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+ ^ ^ +--- encoded ---+ ^ ^ +-- padding --+ 192.0.2.128/25, D = 1 0 1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-------------------------------------------------------------+-+-+-+-+ |1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|1|0|0|0|0|0|0|0| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+-+ ^ ^ +--- encoded ---+ ^ ^ +- padding -+ Figure 1: Prefix Compression Example
The first prefix, 192.0.2.0/28, is considered a master prefix and is transmitted in full. The PLen of 28 bits determines that all four octets must be transmitted. If the prefix would have been, e.g., 192.0.2.0/24, three octets would have sufficed, since 24 bits fit into 3 octets. For the following prefixes, D = 1. Thus, they are deltas of the previous prefix, where D was zero. 192.0.2.64/26 includes bits 19-26 (full octet). Bits 19-25 are copied from the master prefix, but bit 26 is changed to 1. The final notation in binary is "1001", or 0x09. 192.0.2.128/25 includes bits 18-25 (full octet). Bits 18-24 are copied from the master prefix, but bit 25 is changed to 1. The final notation in binary is "101", or 0x05. The final encoding thus becomes +----------------+--------+-+---------------------+ | Prefix | PLen |D| Transmitted Prefix | +----------------+--------+-+---------------------+ | 192.0.2.0/28 | 28 |0| 0xc0 0x00 0x02 0x00 | | 192.0.2.64/26 | 26 |1| 0x09 | | 192.0.2.128/25 | 25 |1| 0x05 | +----------------+--------+-+---------------------+ It should be noted that in this case the order of prefix transmission would not affect compression efficiency. If prefix 192.0.2.128/25 would have been considered the master prefix and the others as deltas instead, the resulting encoding still fits into one octet for the subsequent prefixes. There would be no need to declare a new master prefix.4.2. Realm Compression
4.2.1. Encoding of Compressed Realms
In order to reduce the size of messages, the system introduces a realm compression scheme, which reduces the size of realms in a message. The compression scheme is a simple dynamically updated dictionary-based algorithm, which is designed to compress text strings of arbitrary length. In this scheme, an entire realm, a single label, or a list of labels may be replaced with an index to a previous occurrence of the same string stored in the dictionary. The realm compression defined in this specification was inspired by the RFC 1035 [RFC1035] DNS domain name label compression scheme. Our algorithm is, however, improved to gain more compression.
When compressing realms, the dictionary is first reset and does not
contain a single string. The realms are processed one by one, so the
algorithm does not expect to see them all or the whole message at
once. The state of the compressor is the current content of the
dictionary. The realms are compressed label by label or as a list of
labels. The dictionary can hold a maximum of 128 strings; after
that, a rollover MUST occur, and existing contents will be
overwritten. Thus, when adding the 129th string into the dictionary,
the first entry of the dictionary MUST be overwritten, and the index
of the new string will become 0.
The encoding of an index to the dictionary or an uncompressed run of
octets representing a single label has purposely been made simple,
and the whole encoding works on an octet granularity. The encoding
of an uncompressed label takes the form of one octet as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+
|0| LENGTH | 'length' octets long string.. |
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+
This encoding allows label lengths from 1 to 127 octets. A label
length of zero (0) is not allowed. The "label length" tag octet is
then followed by up to 127 octets of the actual encoded label string.
The index to the dictionary (the "label index" tag octet) takes the
form of one octet as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| INDEX |
+-+-+-+-+-+-+-+-+
The above encodings do not allow generating an output octet value of
zero (0). The encapsulating Mobile IPv4 extension makes use of this
property and uses the value of zero (0) to mark the end of the
compressed realm or to indicate an empty realm. It is also possible
to encode the complete realm using only "label length" tags. In this
case, no compression takes place. This allows the sender to skip
compression -- for example, to reduce computation requirements when
generating messages. However, the receiver MUST always be prepared
to receive compressed realms.
4.2.2. Searching Algorithm
When compressing the input realm, the dictionary is searched for a matching string. If no match could be found, the last label is removed from the right-hand side of the used input realm. The search is repeated until the whole input realm has been processed. If no match was found at all, then the first label of the original input realm is encoded using the "label length" tag, and the label is inserted into the dictionary. The previously described search is repeated with the remaining part of the input realm, if any. If nothing remains, the realm encoding is complete. When a matching string is found in the dictionary, the matching part of the input realm is encoded using the "label index" tag. The matching part of the input realm is removed, and the search is repeated with the remaining part of the input realm, if any. If nothing remains, the octet value of zero (0) is inserted to mark the end of the encoded realm. The search algorithm also maintains the "longest non-matching string" for each input realm. Each time the search in the dictionary fails and a new label gets encoded using the "label length" tag and inserted into the dictionary, the "longest non-matching string" is concatenated by this label, including the separating "." (dot, i.e., hexadecimal 0x2e). When a match is found in the dictionary, the "longest non-matching string" is reset (i.e., emptied). Once the whole input realm has been processed and encoded, all possible suffixes longer than one label are taken from the string and inserted into the dictionary.4.2.3. Encoding Example
This section shows an example of how to encode a set of realms using the specified realm compression algorithm. For example, a message might need to compress the realms "foo.example.com", "bar.foo.example.com", "buz.foo.example.org", "example.com", and "bar.example.com.org". The following example shows the processing of input realms on the left-hand side and the contents of the dictionary on the right-hand side. The example uses hexadecimal representation of numbers.
COMPRESSOR: DICTIONARY:
1) Input "foo.example.com"
Search("foo.example.com")
Search("foo.example")
Search("foo")
Encode(0x03,'f','o','o') 0x00 "foo"
+-> "longest non-matching string" = "foo"
Search("example.com")
Search("example")
Encode(0x07,'e','x','a','m','p','l','e') 0x01 "example"
+-> "longest non-matching string" = "foo.example"
Search("com")
Encode(0x03,'c','o','m') 0x02 "com"
+-> "longest non-matching string" = "foo.example.com"
0x03 "foo.example.com"
0x04 "example.com"
Encode(0x00)
2) Input "bar.foo.example.com"
Search("bar.foo.example.com")
Search("bar.foo.example")
Search("bar.foo")
Search("bar")
Encode(0x03,'b','a','r') 0x05 "bar"
+-> "longest non-matching string" = "bar"
Search("foo.example.com") -> match to 0x03
Encode(0x83)
+-> "longest non-matching string" = NUL
Encode(0x00)
3) Input "buz.foo.example.org"
Search("buz.foo.example.org")
Search("buz.foo.example")
Search("buz.foo")
Search("buz")
Encode(0x03,'b','u','z') 0x06 "buz"
+-> "longest non-matching string" = "buz"
Search("foo.example.org")
Search("foo.example")
Search("foo") -> match to 0x00
Encode(0x80)
+-> "longest non-matching string" = NUL
Search("example.org")
Search("example") -> match to 0x01
Encode(0x81)
+-> "longest non-matching string" = NUL
Search("org")
Encode(0x03,'o','r','g') 0x07 "org"
+-> "longest non-matching string" = "org"
Encode(0x00)
4) Input "example.com"
Search("example.com") -> match to 0x04
Encode(0x84)
Encode(0x00)
5) Input "bar.example.com.org"
Search("bar.example.com.org")
Search("bar.example.com")
Search("bar.example")
Search("bar") -> match to 0x05
Encode(0x85)
Search("example.com.org")
Search("example.com") -> match to 0x04
Encode(0x84)
Search("org") -> match to 0x07
Encode(0x87)
Encode(0x00)
As can be seen from the example, due to the greedy approach of
encoding matches, the search algorithm and the dictionary update
function are not the most optimal. However, we do not claim that the
algorithm would be the most efficient. It functions efficiently
enough for most inputs. In this example, the original input realm
data was 79 octets, and the compressed output, excluding the end
mark, is 35 octets.
5. New Mobile IPv4 Messages and Extensions
This section describes the construction of all new information elements.5.1. Mobile Router Route Optimization Capability Extension
This skippable extension MAY be sent by an MR to an HA in the Registration Request message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Subtype |A|R|S|O| Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional Mobile Router HoA ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 153 (skippable); if the HA does not support route optimization advertisements, it can ignore this request and simply not include any information in the reply. "short" extension format. Subtype 1 Reserved Set to zero; MUST be ignored on reception. A Advertise my networks. If the 'A' bit is set, the HA is allowed to advertise the networks managed by this MR to other MRs. This also indicates that the MR is capable of receiving route optimization Registration Requests. In effect, this allows the MR to work in the CR role. R Request mobile network information. If the 'R' bit is set, the HA MAY respond with information about mobile networks in the same domain. S Solicit prefixes managed by a specific MR. The MR is specified in the Optional Mobile Router HoA field. O Explicitly specify that the requesting router is only able to initiate outgoing connections and not accept any incoming connections, due to a NAT device, stateful firewall, or similar issue on any interface. This is reflected by the HA in the reply and distributed in Prefix Advertisements to other MRs.
Optional Mobile Router HoA
Solicited mobile router's home address. This field is only
included if the 'S' flag is set.
5.2. Route Optimization Reply
This non-skippable extension MUST be sent by an HA to an MR in the
Registration Reply message, if the MR indicated support for route
optimization in the registration message and the HA supports route
optimization.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype |O|N|S| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 49 (non-skippable); "short" extension format.
Subtype 1
O The 'O' flag in the Mobile Router Route Optimization
Capability Extension was set during registration.
N NAT was detected by the HA. This informs the MR that it is
located behind a NAT. The detection procedure is specified
in RFC 3519 [RFC3519] and is based on the discrepancy
between the registration packet's source address and
indicated CoA. The MR can use this information to make
decisions about route optimization strategy.
S Responding to a solicitation. If the 'S' bit was present
in the MR's Route Optimization Capability Extension
(Section 5.1), this bit is set; otherwise, it is unset.
The Reply code indicates whether route optimization has been
accepted. Values of 0..15 indicate assent, and values 16..63
indicate that route optimization is not done.
0 Will do route optimization.
16 Route optimization declined; reason unspecified.
5.3. Mobile-Correspondent Authentication Extension
The Mobile-Correspondent Authentication Extension is included in Registration Requests sent from the MR to the CR. The existence of this extension indicates that the message is not destined to an HA, but another MR. The format is similar to the other authentication extensions defined in [RFC5944], with Security Parameter Indexes (SPIs) replaced by nonce indexes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Nonce Index | Care-of Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Home Nonce Index field tells the CR which nonce value to use when producing the home keygen token. The Care-of Nonce Index field is ignored in requests to remove a binding. Otherwise, it tells the CR which nonce value to use when producing the care-of keygen token. If using a pre-shared key (KRm), the indexes may be set to zero and are ignored on reception. Type 49 (non-skippable); "short" extension format. Subtype 2 Reserved Set to zero; MUST be ignored on reception. Home Nonce Index Home Nonce Index in use. If using a pre-shared KRm, set to zero and ignored on reception. Care-of Nonce Index Care-of Nonce Index in use. If using a pre-shared KRm, set to zero and ignored on reception. Authenticator Authenticator field, by default constructed with First (128, HMAC_SHA1 (KRm, Protected Data)).
The protected data, just like in other cases where the Authenticator
field is used, consists of
o the UDP payload (i.e., the Registration Request or Registration
Reply data),
o all prior extensions in their entirety, and
o the Type, Length, Home Nonce Index, and Care-of Nonce Index of
this extension.
5.4. Care-of Address Extension
The Care-of Address Extension is added to a Registration Reply sent
by the CR to inform the MR of the upcoming tunnel endpoint.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1..n times the following information structure
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 49 (non-skippable); "short" extension format.
Length Total length of the packet. When processing the
information structures, if Length octets have been reached,
this is an indication that the final information structure
was reached as well.
Subtype 3
Care-of Address
Care-of address(es) that may be used for a tunnel with the
MR, in order of priority. Multiple CoAs MAY be listed to
facilitate faster NAT traversal processing.
5.5. Route Optimization Prefix Advertisement Extension
This non-skippable extension MAY be sent by an HA to an MR in the Registration Reply message. This extension is only included when explicitly requested by the MR in the Registration Request message, setting the 'R' flag of the Mobile Router Route Optimization Capability Extension. Implicit prioritization of prefixes is caused by the order of extensions. The extension contains a sequence of information structures. An information structure may consist of either an MR HoA or a network prefix. Any network prefixes following an MR HoA are owned by that MR. An MR HoA MUST be first in the sequence, since one cannot have prefixes without an MR. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1..n times the following information structure +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|M| PLen/Info | Optional Mobile Router HoA (4 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | Optional Prefix (1, 2, 3, or 4 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Realm (1..n characters) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 50 (non-skippable); "long" extension format. Subtype 1 Length Total length of the packet. When processing the information structures, if Length octets have been reached, this is an indication that the final information structure was reached as well. D Delta. If D = 1, the prefix is a delta from the last Prefix, where D = 0. MUST be zero on the first information structure containing a Prefix; MAY be zero or one on subsequent information structures. If D = 1, the Prefix field is one octet in length. See Section 4.1 for details.
M Mobile Router HoA bit. If M = 1, the next field is Mobile
Router HoA, and Prefix and Realm are omitted. If M = 0,
the next field is Prefix followed by Realm, and Mobile
Router HoA is omitted. For the first information
structure, M MUST be set to 1. If M = 1, the 'D' bit is
set to zero and ignored upon reception.
PLen/Info
This field is interpreted differently, depending on whether
the 'M' bit is set or not. If M = 0, the field is
considered to be the PLen field, and the contents indicate
the length of the advertised prefix. The 6 bits allow for
values from 0 to 63, of which 33-63 are illegal. If M = 1,
the field is considered to be the Info field. Permissible
values are 0 to indicate no specific information, or 1 to
indicate "outbound connections only". This indicates that
the target MR can only initiate, not receive, connections
on any of its interfaces (apart from the reverse tunnel to
the HA). This is set if the MR has explicitly requested it
via the 'O' flag in the Mobile Router Route Optimization
Capability Extension (Section 5.1).
Mobile Router HoA
The mobile router's home address. All prefixes in the
following information structures where M = 0 are maintained
by this MR. This field is present only when M = 1.
Prefix The IPv4 prefix advertised. If D = 0, the field length is
PLen bits, rounded up to the nearest full octet. Least-
significant bits starting off PLen (and that are zeros) are
omitted. If D = 1, the field length is one octet. This
field is present only when M = 0.
Realm The Realm that is associated with the advertised Mobile
Router HoA and prefix. If empty, MUST be set to '\0'. For
realm encoding and an optional compression scheme, refer to
Section 4.2. This field is present only when M = 0.
5.6. Home Test Init Message
This message is sent from the MR to the CR when performing the RR procedure. The source and destination IP addresses are set to the MR's HoA and the CR's HoA, respectively. The UDP source port MAY be randomly chosen. The UDP destination port is 434. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Home Init Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 24 Reserved Set to zero; MUST be ignored on reception. Home Init Cookie 64-bit field that contains a random value, the Home Init Cookie.5.7. Care-of Test Init Message
This message is sent from the MR to the CR when performing the RR procedure. The source and destination IP addresses are set to the MR's CoA and the CR's HoA, respectively. The UDP source port MAY be randomly chosen. The UDP destination port is 434. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Care-of Init Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 25 Reserved Set to zero; MUST be ignored on reception.
Care-of Init Cookie
64-bit field that contains a random value, the Care-of Init
Cookie.
5.8. Home Test Message
This message is sent from the CR to the MR when performing the RR
procedure as a reply to the Home Test Init message. The source and
destination IP addresses, as well as UDP ports, are the reverse of
those in the Home Test Init message for which this message is
constructed. As such, the UDP source port is always 434.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 26
Reserved Set to zero; MUST be ignored on reception.
Nonce Index
This field will be echoed back by the MR to the CR in a
subsequent Registration Request's authentication extension.
Home Init Cookie
64-bit field that contains a random value, the Home Init
Cookie.
Home Keygen Token
This field contains the 64-bit home keygen token used in
the RR procedure. Generated from cookie + nonce.
5.9. Care-of Test Message
This message is sent from the CR to the MR when performing the RR procedure as a reply to the Care-of Test Init message. The source and destination IP addresses, as well as UDP ports, are the reverse of those in the Care-of Test Init message for which this message is constructed. As such, the UDP source port is always 434. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 27 Reserved Set to zero; MUST be ignored on reception. Care-of Nonce Index This field will be echoed back by the MR to the CR in a subsequent Registration Request's authentication extension. Care-of Init Cookie 64-bit field that contains a random value, the Care-of Init Cookie. Care-of Keygen Token This field contains the 64-bit care-of keygen token used in the RR procedure. Generated from cookie + nonce.
6. Special Considerations
6.1. NATs and Stateful Firewalls
Mechanisms described in Mobile IP NAT traversal [RFC3519] allow the HA to work with MRs situated behind a NAT device or a stateful firewall. Furthermore, the HA may also detect whether a NAT device is located between the mobile node and the HA. The MR may also explicitly state that it is behind a NAT or firewall on all interfaces, and this information is passed on to the other MRs with the Info field in the Route Optimization Prefix Advertisement Extension (Section 5.5). The HA may also detect NAT and inform the registering MR via the 'N' flag in the Route Optimization Reply Extension (Section 5.2). In the case where one or both of the routers is known to be behind a NAT or is similarly impaired (not able to accept incoming connections), the tunnel establishment procedure needs to take this into account. In the case where the MR is behind a NAT (or firewall) and the CR is not, the MR will, when the tunnel has been established, send keepalive messages (ICMP echo requests) through the tunnel. Until a reply has been received, the tunnel SHOULD NOT be considered active. Once a reply has been received, NAT mapping is in place, and traffic can be sent. The source address may change due to NAT in CoTI and Registration Request messages. This does not affect the process -- the hash values are calculated by the translated address, and the Registration Request will also appear from the same translated address. Unlike communication with the HA, in the case of route optimization, the path used for signaling is not used for tunneled packets, as signaling always uses HoAs, and the MR <-> CR tunnel is from CoA to CoA. It is assumed that even though port numbers may change, NAT processing rarely allocates more than one external IP address to a single internal address; thus, the IP address seen in the Registration Request and tunnel packets remains the same. However, the UDP source port number may be different in the Registration Request and incoming tunnel packets, due to port translation. This must not cause an error situation -- the CR MUST be able to accept tunneling packets from a different UDP source port than what was used in the Registration Request. Since MRs may have multiple interfaces connecting to several different networks, it might be possible that specific MRs may only be able to perform route optimization using specific CoA pairs, obtained from specific networks -- for example, in a case where two MRs have an interface behind the same NAT. A similar case may be
applicable to nested NATs. In such cases, the MR MAY attempt to detect eligible CoA pairs by performing a registration and attempting to establish a tunnel (sending keepalives) with each CoA listed in the Registration Reply's Care-of Address Extension. The eligible pairs should be recorded in the Route Optimization Cache. If a tunnel cannot be established with any CoAs, the MR MAY attempt to repeat the procedure with alternative interfaces. The above information on network topology can also be configured on the MRs either statically or via some external feedback mechanism. If both the MR and the CR are behind two separate NATs, some sort of proxy or hole-punching technique may be applicable. This is out of scope for this document.6.2. Handling of Concurrent Handovers
If both the MR and the CR move at the same time, this causes no issues from the signaling perspective, as all requests are always sent from a CoA to HoAs. Thus, the recipient will always receive the request and can send the reply. This applies even in break-before- make situations where both the MR and the CR get disconnected at the same time -- once the connectivity is restored, one endpoint of the signaling messages is always the HoA of the respective router, and it is up to the HA to provide reachability.6.3. Foreign Agents
Since foreign agents have been dropped from work related to Network Mobility for Mobile IPv4, they are not considered here.6.4. Multiple Home Agents
MRs can negotiate and perform route optimization without the assistance of an HA -- if they can discover each other's existence and thus know where to send registration messages. This document only addresses a logically single HA that distributes network prefix information to the MRs. Problems arise from possible trust relationships; in this document, the HA serves as a way to provide verification that a specific network is managed by a specific router. If route optimization is desired between nodes attached to separate HAs, there are several possibilities. Note that standard high- availability redundancy protocols, such as the Virtual Router Redundancy Protocol (VRRP), can be utilized; however, in such a case, the HA is still a single logical entity, even if it consists of more than a single node.
Several possibilities exist for achieving route optimization between MRs attached to separate HAs, such as a new discovery/probing protocol or routing protocol between HAs or DNS SRV records, or a common Authentication, Authorization, and Accounting (AAA) architecture. There is already a framework for HA to retrieve information from AAA, so it can be considered the most viable possibility. See Section 6.6 for information on a possible way to generalize the method. Any discovery/probing protocols are out of scope for this document.6.5. Mutualness of Route Optimization
The procedure as specified is asymmetric; that is, if bidirectional route optimization is desired while maintaining consistency, the route optimization (RR check and registration) has to be performed in both directions, but this is not strictly necessary. This is primarily a policy decision, depending on how often the mobile prefixes are reconfigured. Consider the case where two networks, A and B, are handled by MRs A and B, respectively. If the routers are set up in such a fashion that route optimization is triggered when the router is forwarding a packet destined to a network prefix in the Route Optimization Cache, the following occurs if a node in network A starts sending ICMP echo requests (ping packets) to a node in network B. MR A sees the incoming ICMP echo request packet from the local network destined to network B. Since network B exists in MR A's Route Optimization Cache, the route optimization process is triggered. The original packet is forwarded via the reverse tunnel toward the HA as normal. MR A completes the RR procedure and registration with MR B, which thus becomes a CR for MR A. A tunnel is created between the routers. MR B updates its routing tables so that network A is reachable via the MR A <-> MR B tunnel. The traffic pattern is now such that packets from network B to network A are sent over the direct tunnel, but the packets from A to B are transmitted via the HA and reverse tunnels. The echo reply that the node in network B sends toward network A triggers the route optimization at MR B in similar fashion. As such, MR B now performs its own registration toward MR A. Upon completion, MR B notices that a tunnel to MR A already exists, and updates its routing table so that network A is now reachable via the (existing) MR A <-> MR B tunnel. From this point onward, traffic is bidirectional.
In this scenario, if MR A does NOT wait for a separate route optimization process (RR check and registration) from MR B, but instead simply updates its routing table to reach network B via the tunnel, problems may arise if MR B has started to manage another network, B', before the information has been propagated to MR A. The end result is that MR B starts to receive packets from network A to network B' via the HA and to network B via the direct tunnel. If reverse path checking or a similar mechanism is in use on MR B, some of the packets from network A could be black-holed. Whether to perform this mutual registration or not thus depends on the situation, and whether MRs are going to start managing additional network prefixes during operation.6.6. Extensibility
The design considerations include several mechanisms that might not be strictly necessary if route optimization were only desired between individual customer sites in a managed network. The registration procedure (with the optional return routability part), which allows CRs to learn an MR's CoAs, is not strictly necessary; the CoAs could have been provided by the HA directly. However, this approach allows the method to be extended to a more generic route optimization. The primary driver for having an HA to work as a centralized information distributer is to provide MRs with not only the knowledge of the other routers, but with information on which networks are managed by which routers. The HA provides the information on all feasible nodes with which it is possible to establish route optimization. If representing a whole mobile network is not necessary -- in effect, the typical mobile node <-> correspondent node situation -- the mechanisms in this document work just as well; the only problem is discovering whether the target correspondent node can provide route optimization capability. This can be performed by not including any prefixes in the information extension -- just the HoA of the MR. In addition, with route optimization for a single node, checks for whether an MR is allowed to represent specific networks are unnecessary, since there are none. Correspondent node/router discovery protocols (whether they are based on probing or a centralized directory beyond the single HA) are outside the scope of this document.
6.7. Load Balancing
This design simply provides the possibility of creating optimal paths between MRs; it doesn't dictate what the user traffic using these paths should be. One possible approach in helping facilitate load balancing and utilizing all available paths is presented in [MIPv4FLOW], which effectively allows for multiple CoAs for a single HoA. In addition, per-tunnel load balancing is possible by using separate CoAs for separate tunnels.7. Scalability
Home agent-assisted route optimization scalability issues stem from the general Mobile IPv4 architecture, which is based on tunnels. Creating, maintaining, and destroying tunnel interfaces can cause load on the MRs. However, the MRs can always fall back to normal, reverse-tunneled routing if resource constraints are apparent. If there are a large number of optimization-capable prefixes, maintaining state for all of these may be an issue also, due to limits on routing table sizes. Registration responses from the HA to the MR may provide information on a large number of network prefixes. If thousands of networks are involved, the Registration Reply messages are bound to grow very large. The prefix and realm compression mechanisms defined in Section 4 mitigate this problem to an extent. There will, however, be some practical upper limit, after which some other delivery mechanism for the prefix information will be needed.
8. Example Signaling Scenarios
8.1. Registration Request
The following example assumes that there are three mobile routers -- MR A, MR B, and MR C -- each managing network prefixes A, B, and C. At the beginning, no networks are registered with the HA. Any AAA processing at the HA is omitted from the diagram. +--------+ +--------+ +--------+ +--------------+ | [MR A] | | [MR B] | | [MR C] | | [Home Agent] | +--------+ +--------+ +--------+ +--------------+ | | | | x------------------------------->| Registration Request | | | | includes Mobile Router | | | | Route Optimization | | | | Capability Extension | | | | |<-------------------------------x Registration response; | | | | no known networks from HA | | | | in response | | | | | x-------------------->| Registration Request similar | | | | to the one sent by MR A | | | | | |<--------------------x Registration Reply includes | | | | network A in Route Optimization | | | | Prefix Advertisement Extension | | | | | | x--------->| Registration Request similar | | | | to the one sent by MR A | | | | | | |<---------x Registration Reply includes | | | | networks A and B in Route | | | | Optimization Prefix | | | | Advertisement Extension. | | | | Network B is sent in | | | | compressed form. | | | |
8.2. Route Optimization with Return Routability
The following example has the same network setup as that in Section 8.1 -- three MRs, each corresponding to their respective network. Node A is in network A, and Node C is in network C. At the beginning, none of the MRs know each other's KRms. If the KRms were pre-shared or provisioned with some other method, the Return Routability messages could be omitted. Signaling as described in Section 8.1 has occurred; thus, MR A is not aware of the other networks, and MR C is aware of networks A and B. ======= Traffic inside Mobile IP tunnel to/from HA =-=-=-= Traffic inside Mobile IP tunnel between MRs ------- Traffic outside Mobile IP tunnel +----------+ +--------+ +------+ +--------+ +----------+ | [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] | +----------+ +--------+ +------+ +--------+ +----------+ | | | | | x------------O==========O=========O------>| Mobile Router A is | | | | | unaware of network C; | | | | | thus, nothing happens | | | | | |<-----------O==========O=========O-------x Mobile Router C | | | | | notices packet to | | | | | network A - begins | | | | | route optimization | | | | | | | | | | Return Routability (if | | | | | no pre-shared KRms) | | | | | | |<=========O---------x | CoTI | |<=========O=========x | HoTI | | | | | | x==========O-------->| | CoT | x==========O========>| | HoT | | | | | | | | | | KRm between MR A <-> C | | | | | established | | | | | | |<=========O---------x | Registration Request | | | | | | x--------->| | | Registration Request | | | | | to HA due to MR A | | | | | being unaware of | | | | | network C. | | | | | Solicit bit set.
| | | | | | |<---------x | | Registration Reply | | | | | contains info on | | | | | network A | | | | | | x==========O-------->| | Registration Reply | | | | | includes MR A's CoA in | | | | | Care-of Address | | | | | Extension | | | | | | |<= = = = =O= = = ==>| | Optional mutual | | | | | registration from | | | | | MR A to MR C | | | | | (same procedure as above, | | | | | multiple packets); | | | | | possible keepalive checks | | | | | |<-----------O=-=-=-==-=-=-=-==-=-O-------x Packet from Node C -> A | | | | | routed to direct tunnel | | | | | at MR C, based on | | | | | MR C now knowing MR A's | | | | | CoA and tunnel being up | | | | | x------------O=-=-=-==-=-=-=-==-=-O------>| Packet from Node A -> C | | | | | routed to direct tunnel | | | | | at MR A, based on MR A | | | | | now knowing MR C's CoA | | | | | and tunnel being up8.3. Handovers
In this signaling example, MR C changes its CoA while route optimization between MR A and MR C is operating and data is being transferred. Cases where the handover is graceful ("make before break") and ungraceful ("break before make") both occur in similar fashion, except that in the graceful version no packets are lost. This diagram considers the case where MR C gets immediate notification of lost connectivity, e.g., due to a link status indication. MR A would eventually notice the breakdown, due to keepalive messages failing.
======= Traffic inside Mobile IP tunnel to/from HA
=-=-=-= Traffic inside Mobile IP tunnel between MRs
------- Traffic outside Mobile IP tunnel
+----------+ +--------+ +------+ +--------+ +----------+
| [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] |
+----------+ +--------+ +------+ +--------+ +----------+
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Nodes A and C are
|<-----------O=-=-=-==-=-=-=-==-=-O-------x exchanging traffic
| | | | |
| | xxxxxxxxxxx | Break occurs: MR C
| | | | | loses connectivity to
| | | | | current attachment point
| | | | |
x------------O=-=-=-==-=-=-=->x | | Traffic from A -> C
| | | | | lost, and
| | | x<=-=-O-------x vice versa
| | | | |
| | |<--------x | MR C finds a new
| | | | | point of attachment,
| | | | | registers with the HA,
| | | | | clears routing tables
| | | | |
| | x-------->| | Registration Reply
| | | | |
x------------O=-=-=-==-=-=-=->x | | Traffic from A -> C lost
| | | | | (reverts to routing via
| | | | | HA if enough keepalives
| | | | | fail)
| | | | |
|<-----------O==========O=========O-------| Traffic from C -> A
| | | | | sent via HA
| | | | |
| O<=========O---------x | CoTI message
| | | | | (partial RR check)
| | | | |
| x==========O-------->| | CoT message
| | | | |
| |<=========O---------x | Registration Request
| | | | | reusing newly calculated
| | | | | KRm
| | | | |
| x==========O-------->| | Registration Reply
| | | | |
| O<=-=-=-=-=-=-=-=-=-=x | First keepalive check if
| | | | | using UDP encapsulation;
| | | | | also creates holes in
| x=-=-=-=-=-=-=-=-=-=>| | firewalls
| | | | |
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Traffic from A -> C
| | | | | forwarded directly again
| | | | |
|<-----------O=-=-=-==-=-=-=-==-=-O-------x Traffic from C -> A
| | | | | switches back to direct
| | | | | tunnel
| | | | |
9. Protocol Constants
MAX_NONCE_LIFETIME 240 seconds
MAX_TOKEN_LIFETIME 210 seconds
MAX_UPDATE_RATE 5 times
10. IANA Considerations
IANA has assigned rules for the existing registries "Mobile IP
Message Types" and "Extensions to Mobile IP Registration Messages",
specified in RFC 5944 [RFC5944]. New Mobile IP message types and
extension code allocations have been made for the messages and
extensions listed in Section 5.
The route optimization authentication processing requires four new
message type numbers. The new Mobile IP Message types are listed
below, in Table 1.
+-------+---------------------------+
| Value | Name |
+-------+---------------------------+
| 24 | Home Test Init message |
| 25 | Care-of Test Init message |
| 26 | Home Test message |
| 27 | Care-of Test message |
+-------+---------------------------+
Table 1: New Values and Names for Mobile IP Message Types
Three new registration message extension types are required and listed in Table 2. The first type, 153, is skippable and has been allocated from range 128-255. The other two, 49 and 50, are non-skippable and have been allocated from range 0-127, with 49 being of the "short" format and 50 being of the "long" format. None of the messages are permitted for notification messages. +--------------+---------------------------------------------+ | Value | Name | +--------------+---------------------------------------------+ | 153, 128-255 | Mobile Router Route Optimization Indication | | 49, 0-127 | Route Optimization Extensions | | 50, 0-127 | Route Optimization Data | +--------------+---------------------------------------------+ Table 2: New Values and Names for Extensions in Mobile IP Registration Messages In addition, the registry "Code Values for Mobile IP Registration Reply Messages" has been modified. A new success code, 2, should be allocated as follows: 2 Concurrent registration (pre-accept) In addition, a new allocation range has been created as "Error Codes from the Correspondent Node", subject to the policy of Expert Review [RFC5226]. The range is 201-210. Three new Registration Reply codes have been allocated from this range. They are specified in Table 3, below: +-------+-----------------------------+ | Value | Name | +-------+-----------------------------+ | 201 | Expired Home nonce Index | | 202 | Expired Care-of nonce Index | | 203 | Expired nonces | +-------+-----------------------------+ Table 3: New Code Values and Names for Mobile IP Registration Reply Messages
Three new number spaces were required for the subtypes of the extensions in Table 2. A new registry, named "Route Optimization Types and Subtypes", has been created with an allocation policy of RFC Required [RFC5226]. The registration entries include Type, Subtype, and Name. Type and Subtype have a range of 0-255. Types are references to registration message extension types. Subtypes are allocated initially as in Table 4, below: +------+---------+--------------------------------------------------+ | Type | Subtype | Name | +------+---------+--------------------------------------------------+ | 153 | 0 | Reserved | | 153 | 1 | Mobile Router Route Optimization Capability | | | | Extension | | 49 | 0 | Reserved | | 49 | 1 | Route Optimization Reply | | 49 | 2 | Mobile-Correspondent Authentication Extension | | 49 | 3 | Care-of Address Extension | | 50 | 0 | Reserved | | 50 | 1 | Route Optimization Prefix Advertisement | | | | Extension | +------+---------+--------------------------------------------------+ Table 4: Initial Values and Names for Registry Route Optimization Types and Subtypes11. Security Considerations
There are two primary security issues: One issue relates to the RR check, which establishes that a specific CoA is, indeed, managed by a specific HoA. The other issue is trust relationships and an arbitrary router claiming to represent an arbitrary network. The end-user traffic can be protected using normal IPsec mechanisms.11.1. Return Routability
The RR check's security has been vetted with Mobile IPv6. There are no major differences, apart from two issues: connectivity check and replay attack protection. The connectivity check is conducted with a separate ICMP message exchange. Replay attack protection is achieved with Mobile IPv4 timestamps in the Registration Request's Identification field, in contrast to the sequence numbers used in Mobile IPv6. The RR procedure does not establish any kind of state information on the CR; this mitigates denial-of-service attacks. State information is only maintained after a Registration Request has been accepted.
11.2. Trust Relationships
The network of trust relationships in home agent-assisted route optimization solves possible trust issues: An arbitrary CR can trust an arbitrary MR that it is indeed the proper route to reach an arbitrary mobile network. It is assumed that all MRs have a trust relationship with the HA. Thus, they trust information provided by the HA. The HA provides information matching HoAs and network prefixes. Each MR trusts this information. MRs may perform the RR procedure between each other. This creates a trusted association between the MR's HoA and CoA. The MR also claims to represent a specific network. This information is not trustworthy as such. The claim can be verified by checking the HoA <-> network prefix information received, either earlier, or due to an on-demand request, from the HA. If they match, the MR's claim is authentic. If the network is considered trusted, a policy decision can be made to skip this check. Exact definitions on situations where such decisions can be made are out of scope for this document. The RECOMMENDED general practice is to perform the check.12. Acknowledgements
Thanks to Alexandru Petrescu for constructive comments and support. Thanks to Jyrki Soini and Kari Laihonen for initial reviews. This work was supported by TEKES as part of the Future Internet program of TIVIT (Finnish Strategic Centre for Science, Technology and Innovation in the field of ICT).13. References
13.1. Normative References
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003. [RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, "Network Mobility (NEMO) Extensions for Mobile IPv4", RFC 5177, April 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.13.2. Informative References
[MIP-RO] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress, September 2001. [MIPv4FLOW] Gundavelli, S., Ed., Leung, K., Tsirtsis, G., Soliman, H., and A. Petrescu, "Flow Binding Support for Mobile IPv4", Work in Progress, February 2012. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
Authors' Addresses
Antti Makela Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto FINLAND EMail: antti.t.makela@iki.fi Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo FINLAND EMail: jouni.nospam@gmail.com