Download Mobile IP

Mobile Networks
Module E
Mobile Network Layer
J.-P. Hubaux, N. Vratonjic, M. Poturalski, I. Bilogrevic
http://mobnet.epfl.ch
Some slides addapted from Jochen H. Schiller (www.jochenschiller.de)
1
Enablers of IP mobility

Mobile end systems
Laptops
PDAs
Smart-phones
…

Wireless technologies
Wireless LANs (IEEE 802.11)
Bluetooth (www.bluetooth.com)

Improved batteries (longer lifetime)
2
Problem with IP mobility
IP1
WLAN 802.11
mail.epfl.ch
IP2
WLAN 802.11
Need to establish a new TCP
connection, old connection broken
Assign a new IP address via DHCP
3
IP mobility and cellular networks
GSM Network 2G
• Assign IP address
• Tunnel IP packets
• Always in the path
GPRS (or EDGE or UMTS) tunnel
IP link
IP1
BTS
GGSN
BSC
GPRS Access
SGSN
IP1
IP1
Core Network
mail.epfl.ch
BSC
BTS
WLAN 802.11
CN
Internet
IP2
• Assign a new IP address via DHCP
Possible solution: Generic Access Network (GAN)
a.k.a. Unlicensed Mobile Access (UMA)
4
TCP/IP was not designed for mobility


Change of IP address means disconnection of the application
TCP interprets dropped packets (channel errors,
disconnections) as congestion
More on this issue in Module F

Limitations due to a fundamental design problem
The IP address (network layer) has a dual role
 Network locator (topological point of attachment) for
routing purposes
 Host identifier (unique for a host and TCP/IP stack)
5
Routing in the Internet

Routing is based on the destination IP address
Network prefix (e.g. 129.13.42) determines physical subnet

Change of physical subnet implies change of IP address
(standard IP)
The new IP address needs to be topologically correct (belong to
the new subnet) to be routable

Changing the IP address according to the current location
DHCP provides plug-and-play address update
Number of drawbacks:
Almost impossible to locate a mobile system; long delays for
DNS updates
TCP connections break
Security problems
6
Update routing tables?

Quick ‘solution’
Keep IP address constant
Update routing tables to forward packets to the right location

Not feasible
Does not scale with number of mobile hosts and frequent
changes in location
Routers are designed for fast forwarding, not fast
updates
Routers have limited memory (cannot store separate
entry for every mobile host)
Route updates consume network throughput
Security problems
7
Two main solutions

Mobile IP
Support mobility transparently to TCP and applications
Rely on existing protocols

Host Identity Protocol (HIP)
A new layer between IP and transport layers
Architectural change to TCP/IP structure
8
Mobile IP
Requirements to Mobile IP

Transparency
Mobile end-systems (hosts) keep their IP address
Maintain communication in spite of link breakage
Enable change of point of connection to the fixed network

Compatibility
Support the same Layer 2 protocols as IP
No changes to current end-systems and routers
Mobile end-systems can communicate with fixed systems

Security
Authentication of all registration messages

Efficiency and scalability
Only little additional messages to the mobile system required
(connection may be over a low-bandwidth radio link)
World-wide support of a large number of mobile systems
10
Terminology

Mobile Node (MN)
 Entity (node) that can change its point of connection
to the network without changing its IP address

Home Agent (HA)
 Entity in the home network of the MN, typically a router
 Registers the MN location, encapsulates and tunnels IP packets to the COA

Foreign Agent (FA)
 System in the current foreign network of the MN, typically a router
 Decapsulates and forwards the tunneled packets to the MN

Care-of Address (COA)
 Address of the current tunnel end-point for the MN
Foreign Agent COA or
Co-located COA (no FA, MN performs decapsulation)
 Actual location of the MN from an IP point of view
 Co-located COA typically acquired via DHCP

Correspondent Node (CN)
 Communication partner
11
Data transfer to the mobile node:
HA
2
MN
home network
Internet
receiver
3
FA
1
CN
sender
foreign
network
1. Sender sends to the IP address of MN,
HA intercepts packet (proxy ARP)
2. HA tunnels packet to COA, here FA,
by encapsulation
3. FA forwards the packet
to the MN
12
Data transfer with co-located COA
HA
2
MN
Internet
home network
receiver
3
1
CN
sender
foreign
network
1. Sender sends to the IP address of MN,
HA intercepts packet (proxy ARP)
2. HA tunnels packet to co-located COA
(MN) by encapsulation
3. MN decapsulates and (internally)
delivers packet to home address
13
Data transfer from the mobile node
HA
4
home network
MN
sender
Internet
FA
foreign
network
4. Sender sends to the IP address
of the receiver as usual,
FA works as default router
CN
receiver
14
Mobile IP mechanisms

Agent Discovery
MN discovers its location (home network, foreign network)
MN learns a COA

Registration
MN securely signals the COA to the HA (via the FA)

Tunneling
HA encapsulates IP packets from CN and sends them to the
COA
FA (or MN) decapsulates these packets and sends them to
the MN
15
Agent discovery

Agent Advertisement
HA and FA periodically send advertisement messages into their
physical subnets
MN listens to these messages and detects, if it is in the home or a
foreign network (standard case for home network)
MN reads a COA from the FA advertisement messages

Agent Solicitation
MN can request an Agent Advertisement message with a Agent
Solicatation message
Helps decrease disconnection time

Simple extension of ICMP Router Discovery
(ICMP: Internet Control Message Protocol)

Other mechanisms can be used to discover the network
and the COA (e.g. DHCP)
16
Agent advertisement
0
7 8
type
#addresses
RFC 1256
15 16
23 24
checksum
lifetime
31
code
addr. size
router address 1
preference level 1
router address 2
preference level 2
...
type = 16
type = 16
length
sequence number
length = 6 + 4 * #COAs
R B H F M G r T reserved
registration lifetime
R: registration required
COA 1
B: busy, no more registrations
COA 2
H: home agent
F: foreign agent
...
M: minimal encapsulation
G: GRE (Generic Routing Encapsulation)
r: =0, ignored (former Van Jacobson compression)
T: FA supports reverse tunneling
reserved: =0, ignored
17
Registration
Mobility Binding
Home address COA
Registration lifetime
Note: with co-located COA, MN sends
registation request directly to HA
Foreign
Agent
2. Registration request
Home
Agent
4. Registration reply
3. If OK, sets up the binding
1. Registration
request
5. Registration reply
Note: HA can allow for multiple
simultanous mobilty bindings.
In that case, a packet from CN is
forwarded to all active COAs
Mobile Node
(COA)
18
Mobile IP registration request
0
7 8
type = 1
UDP
message
15 16
S B DMG r T x
home address
home agent
COA
23 24
lifetime
31
identification
extensions . . .
S: simultaneous bindings
B: broadcast datagrams
D: decapsulation by MN
M: mininal encapsulation
G: GRE encapsulation
r: =0, ignored
T: reverse tunneling requested
x: =0, ignored
identification:
generated by MN, used for matching requests with
replies and preventing replay attacks (must contain
a timestame and/or a nonce)
extensions:
mobile-home authentication extension (mandatory)
mobile-foreign authentication extension (optional)
foreign-home authentication extension (optional)
19
Mobile IP registration reply
0
7 8
type = 3
UDP
message
15 16
code
home address
home agent
31
lifetime
identification
Example codes:
extensions . . .
registration successful
0 registration accepted
1 registration accepted, but simultaneous mobility bindings unsupported
registration denied by FA
65 administratively prohibited
66 insufficient resources
67 mobile node failed authentication
68 home agent failed authentication
69 requested Lifetime too long
registration denied by HA
129 administratively prohibited
131 mobile node failed authentication
133 registration Identification mismatch
135 too many simultaneous mobility bindings
20
Security associations and registration keys
Foreign
Agent
Home
Agent
Mobile Node


Usually, there is a security association (SA) between the home agent
(HA) and the mobile node (MN)
Possible techniques to establish a registration key between the mobile
node and the foreign agent (FA):




Make use of Internet Key Exchange (IKE), if available
If HA and FA share a SA, the HA can provide the registration
Make use of the public key of the FA or of the MN
Diffie-Hellman key exchange protocol between FA and MN
21
Tunneling
Correspondent
Node
Src Dest Payload
CN MN abcdefghij
1
Binding
2
Foreign
Agent
Src Dest Src Dest Payload
HA COA CN MN abcdefghij
Home
Agent
Encapsulated datagram
3
Src Dest Payload
CN MN abcdefghij
Mobile Node
22
IP-in-IP encapsulation


IP-in-IP-encapsulation
(RFC 2003, updated by RFCs 3168, 4301, 6040)
ver.
IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
IP-in-IP
IP checksum
IP address of HA
Care-of address COA
ver. IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
lay. 4 prot.
IP checksum
IP address of CN
IP address of MN
TCP/UDP/ ... payload
IHL: Internet Header Length
TTL: Time To Live
DS: Differentiated Service
TOS: Type of Service
23
Minimal encapsulation

Minimal encapsulation (optional)
avoids repetition of identical fields
e.g. TTL, IHL, version, DS (RFC 2474, old: TOS)
only applicable for non fragmented packets, no space left for
fragment identification
ver.
IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
min. encap.
IP checksum
IP address of HA
care-of address COA
lay. 4 protoc. S reserved
IP checksum
IP address of MN
original sender IP address (if S=1)
TCP/UDP/ ... payload
24
Generic Routing Encapsulation
outer header
new header
RFC 1701
IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
GRE
IP checksum
IP address of HA
Care-of address COA
C R K S s rec.
rsv.
ver.
protocol
checksum (optional)
offset (optional)
key (optional)
sequence number (optional)
routing (optional)
ver.
IHL
DS (TOS)
length
IP identification
flags
fragment offset
TTL
lay. 4 prot.
IP checksum
IP address of CN
IP address of MN
GRE
header
original
header
original data
original
header
original data
new data
ver.
RFC 2784 (updated by 2890)
C
reserved0
ver.
checksum (optional)
protocol
reserved1 (=0)
TCP/UDP/ ... payload
25
“Triangle” routing
Correspondent
Node
Home
Agent
Mobile
Node

Foreign
Agent
Drawbacks
Inefficiency
MN sends IP packets with topologically incorrect source
For security reasons, router can be configured to drop
topologically incorrect packets (ingress filtering)
26
Route Optimization in Mobile IP


Route optimization
HA provides the CN with the current location of MN (FA)
CN sends tunneled traffic directly to FA
Optimization of FA handover
Packets on-the-fly during FA change can be lost
New FA informs old FA to avoid packet loss, old FA now
forwards remaining packets to new FA
This information also enables the old FA to release
resources for the MN
27
Route and FA handover optimizations
CN
HA
FAnew
FA
MN
Request
Update
ACK
Data
Data
Update
ACK
Data
Warning
Warning
Data
Data
New
request
Registration
MN changes
location
Data
Data
Request
Update
ACK
Data
Data
28
Reverse tunneling
HA
2
MN
home network
Internet
sender
1
FA
3
CN
receiver
foreign
network
1. MN sends to FA
2. FA tunnels packets to HA
by encapsulation
3. HA forwards the packet to the
receiver (standard case)
29
Mobile IP with reverse tunneling

Reverse tunneling solves ingress filtering problem
A packet from the MN encapsulated by the FA is now topologically
correct
Can cope with mobile routers
Protects MN location privacy
Multicast and TTL problems solved

Reverse tunneling does not solve
Optimization of data paths
Double triangular routing
Problems with firewalls
The reverse tunnel can be abused to circumvent security
mechanisms (tunnel hijacking)
30
Firewalls
Correspondent
Domain
Correspondent
Node
Filtering of incoming packets:
Discard packets that seem to emanate
from an address internal to the domain
(even if they are tunneled)
FW
Home Domain
Global
Internet
FW
Home
Agent
FW
Foreign
Domain
Foreign
Agent
Mobile
Node
Filtering of outgoing packets: discard packets that seem
to emanate from an address external to the domain
(even if they are tunneled)
Possible solutions:
• Manual configuration
• Isolation of Mobile Nodes
(pockets)
31
Mobile IP and IPsec

Security in Mobile IP
Authentication in registration messages
No protection of data transmission (tunneling)

IPsec provides general IP layer security
Can be used to protect data transmission
Can also be used in addition/in place of default registration
messages authentication
32
IPsec: Brief reminder
Application
Application
TCP or UDP
TCP or UDP
Security Association
IP
Data link
IPsec
mechanisms



IP
Data link Data link
IP
Data link
Router
Provides confidentiality, authentication and integrity
IPsec support is optional in IPv4, mandatory in IPv6
Security Association (SA) consists of a suite of
cryprographic algorithms and keys
Security Parameter Index (SPI) is used for indexing SAs
33
IPsec: Authentication Header
Input IP packet:
...
src IP dst IP
- authenticated
with auth
payload
IP header
AH transport mode:
src IP dst IP
...
SPI
seq
auth
payload
auth
IP header
AH
IP header
AH tunnel mode:
src IP’ dst IP’ ...
new IP header


SPI
seq
AH
Provides authentication and integrity
Cannot traverse NATs
IP addresses authenticated
payload
input IP packet
34
IPsec: Encapsulating Security Payload
Input IP packet:
...
src IP dst IP
- encrypted
payload
- authenticated
with auth
IP header
ESP transport mode:
...
src IP dst IP SPI
seq
payload
auth
ESP
IP header
ESP tunnel mode:
...
src IP’ dst IP’ SPI
IP header


seq
input IP packet
auth
ESP
Provides confidentiality, authentication and integrity
Outer IP header not authenticated
35
Mobile IPv6

Mobile IPv6 introduces several modifications based
on new IPv6 functionality and experiences with
Mobile IPv4
No FA, COA is always co-located
Two modes of operation:
Bidirectional tunnel (between HA and COA)
Route optimization (MN informs CN about the COA)
Security integrated with IPsec (mandatory support in IPv6)
“Soft“ hand-over, i.e. without packet loss, between two
subnets is supported
MN sends the new COA to its old router
The old router encapsulates all incoming packets for the
MN and forwards them to the new COA
36
IP Micro-mobility support

Micro-mobility support:
Efficient local handover inside a foreign domain
without involving a home agent
Reduces control traffic on backbone
Especially needed in case of route optimization

Example:
Hierarchical Mobile IP (HMIP)

Important criteria:
Security Efficiency, Scalability, Transparency,
Manageability
37
Hierarchical Mobile IPv6

Operation:
Network contains mobility anchor point (MAP)
mapping of regional COA (RCOA) to link COA
(LCOA)
Upon handover, MN informs
Internet
HA
MAP only
gets new LCOA, keeps RCOA
HA is only contacted if MAP
RCOA
changes

Security provisions:
No HMIP-specific
security provisions
Binding updates should be
authenticated
(AR: Access Router)
MAP
binding
update
AR
AR
LCOAnew LCOAold
MN
MN
38
Hierarchical Mobile IP: Security

Advantages:
Local COAs can be hidden,
which provides at least some location privacy
Direct routing between CNs sharing the same link is
possible (but might be dangerous)

Potential problems:
Decentralized security-critical functionality
(handover processing) in mobility anchor points
MNs can (must!) directly influence routing entries via binding
updates (authentication necessary)
39
Hierarchical Mobile IP: Other issues

Advantages:
Handover requires minimum number
of overall changes to routing tables
Integration with firewalls / private address support possible

Potential problems:
Not transparent to MNs
Handover efficiency in wireless mobile scenarios:
Complex MN operations
All routing reconfiguration messages
sent over wireless link
40
Mobile IP summary


A mobile network layer compatible with the current
deployed Internet protocol stack
Issues with Mobile IP
Security
Authentication with FA can be problematic, because the
FA typically belongs to another organization
Firewalls
Typically mobile IP cannot be used together with
firewalls, special set-ups are needed
QoS
Tunneling makes it hard to give a flow of packets a
special treatment needed for the QoS
41
Host Identity Protocol (HIP)
42
Architectural background

Two global name spaces in the current Internet:
Domain names
IP addresses

Recall: IP addresses have a dual role
1. Identifiers
2. Locators

Duality makes many things difficult
43
New requirements to Internet addressing

Mobile Hosts
Need to change IP address dynamically

Multi-interface hosts
Have multiple independent addresses

Challenge: Mobile and multi-interface hosts
Multiple dynamically changing addresses
44
HIP: A new global Internet name space






Decouples the name and locator roles of IP
addresses
Architectural change to TCP/IP structure
A new layer between IP and transport layers
Introduces cryptographic Host Identifiers
Integrates security, mobility and multi-homing
Opportunistic host-to-host IPsec ESP
End-host mobility, across IPv4 and IPv6
End-host multi-address multi-homing, IPv4/v6
IPv4/v6 interoperability for applications
45
HIP: A new layer
Process
Transport
Host Identity
IP layer
<IP addr, port>
<Host ID, port>

Sockets bound to Host
Identities (HIs), not to IP
addresses
Host ID
IP address
Link Layer
46
HIP bindings
47
HIP overview






HIP identifiers
Establishing a shared context between two host
HIP base exchange
Data communication
By default protected with IPsec ESP
Mobility during data communication
HIP locator update
Finding a host
HIP DNS extensions
HIP Rendezvous extension
Multihoming
48
HIP identifiers


Host Identifiers (HIs)
A host holds a key pair (private and public key)
Host Identifier (HI) = public key
HI representation: Host Identity Tag (HIT)
HIT = h(HI) (h – cryptographic hash function, 128bits)
Advantages:
Fixed length makes for easier protocol coding and better
manages the packet size cost
Independent of cryptographic protocols used for public
private keys
Collision probability (birthday paradox)
With 1012 hosts P(collision) < 1.5∙10-15
49
HIP base exchange
Initiator (I)
Responder (R)
I1: IPI, IPR, HITI, HITR
R1: IPI, IPR, HITI, HITR, DHR, HIR, sig, ESPtransform, puzzle
I2: IPI, IPR, HITI, HITR, DHI, HII, sig, ESPtransform, ESPinfo, solution
R2: IPI, IPR, HITI, HITR, sig, ESPinfo

Establishes HIP association (addressing part)
HII ↔ IPI ↔ IPR ↔ HIR

Used by the HIP layer to map between HIs and IPs
50
HIP base exchange
Initiator (I)
Responder (R)
I1: IPI, IPR, HITI, HITR
R1: IPI, IPR, HITI, HITR, DHR, HIR, sig, ESPtransform, puzzle
I2: IPI, IPR, HITI, HITR, DHI, HII, sig, ESPtransform, ESPinfo, solution
R2: IPI, IPR, HITI, HITR, sig, ESPinfo
DHI/R – Diffie-Hellman key material
sig – signature generated with private key of HII/R
Diffie-Hellman
generates a shared secret
Signatures
protect message integrity
prove that hosts possess private keys corresponding to their
declared HIs
51
HIP base exchange
Initiator (I)
Responder (R)
I1: IPI, IPR, HITI, HITR
R1: IPI, IPR, HITI, HITR, DHR, HIR, sig, ESPtransform, puzzle
I2: IPI, IPR, HITI, HITR, DHI, HII, sig, ESPtransform, ESPinfo, solution
R2: IPI, IPR, HITI, HITR, sig, ESPinfo
ESPtransform – supported cryptographic suites
ESPinfo – contains the Security Parameter Index (SPI)
ESP
Full
keys are generated from the Diffie-Hellman secret
HIP association (basic case):
HII
SPIIR
SPIRI
IPI
IPR
SPIIR
SPIRI
HIR
52
HIP base exchange
Initiator (I)
Responder (R)
I1: IPI, IPR, HITI, HITR
R1: IPI, IPR, HITI, HITR, DHR, HIR, sig, ESPtransform, puzzle
I2: IPI, IPR, HITI, HITR, DHI, HII, sig, ESPtransform, ESPinfo, solution
R2: IPI, IPR, HITI, HITR, sig, ESPinfo

Cryptographic puzzle mitigates DoS against R
Makes HIP base exchange more costly for I than for R
R remains stateless until correct I2 arrives
R1: R chooses puzzle from a pre-computed pool
I computes solution based on puzzle challenge and HITs
I2: R verifies solution and only then allocates state for I
53
Mobile Host
Mobility with HIP
IP Address 1
Correspondent
Host
Mobile Host
UPDATE(ESP_INFO, LOCATOR, SEQ)
IP Address 2
UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
UPDATE(ACK, ECHO_RESPONSE)



LOCATOR indicates the new IP address and its lifetime
ESP_INFO contains old and new SPIs (can be the same)
HIP association is updated accordingly:
HIM
SPIMC
SPICM
new
IP1
...
HIM
SPIMC
new
SPICM
IP2
...
54
Mobile Host
Mobility with HIP
IP Address 1
Correspondent
Host
Mobile Host
IP Address 2
UPDATE(ESP_INFO, LOCATOR, SEQ)
UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
UPDATE(ACK, ECHO_RESPONSE)



UPDATE is protected by HMAC and HIP_SIGNATURE
UPDATE is explicitly acknowledged (SEQ and ACK numbers)
ECHO_REQUEST and ECHO_RESPONSE verify that MH is
reachable at the new address
No data is sent to new IP if this verification fails
Mitigates DoS attacks against new IP
55
HIP DNS extensions

Traditionally DNS maps domain names to IP
addresses

HIP-enabled DNS in addition can map a domain
name to:
Host Identifier (HI)
Host Identifier Tag (HIT)
Rendezvous Server (RVS)
56
HIP and DNS: static case
DNS
FQDNSH
HISH, HITSH, IPSH
I1: IPCH, IPSH, HITCH, HITSH
R1: IPCH, IPSH, HITCH, HITSH
Correspondent
Host
I2: IPCH, IPSH, HITCH, HITSH
R2: IPCH, IPSH, HITCH, HITSH
Static
Host
57
FQDN: Fully Qualified Domain Name
HIP and DNS: mobile case
DNS
RVS
(details in RFC 5203)
UPDATE IP
FQDNMH
Mobile Host
new IP address
HIMH, HITMH, IPRVS
I1: IPCH, IPRVS, HITCH, HITMH
I1: IPRVS, IPMH, HITCH, HITMH
R1: IPCH, IPMH, HITCH, HITMH
Correspondent
Host
I2: IPCH, IPMH, HITCH, HITMH
R2: IPCH, IPMH, HITCH, HITMH
Mobile
Host
58
FQDN: Fully Qualified Domain Name
Multihoming with HIP


Multihoming: a host has multiple IP interfaces
Increases reliability
HIP locator update mechanism enables multihoming
Multihomed host provides Correspondent with multiple IP
adresses (can also idicate a prefered one)

More complex HIP associations
RFC recommends separate SPI per physical interface
HI
SPI pairA
IPA (preferred)
SPI pairB
IPB
SPI pairC
IPC
IPD
59
HIP summary





New namespace for the Internet
between IP and domain names
Integrates security, mobility, and multihoming
Main disadvantage:
Requires update of the transport layer stack on all end hosts
Transparent and scalable
Applications for HIP
Mobile VPN user
VoIP (notably handover)
Search in peer-to-peer systems
Faster WLAN access control
Device peering
60
Generic Access Network (GAN)

Access to cellular networks over unlicensed spectrum
technologies (WiFi, Bluetooth)
Unlicensed Mobile Access (UMA) is the commercial name
61
http://www.umatechnology.org/overview/
GAN Deployment

Initial specifications published in 2004
Written by operators and equipment manufacturers
Alcatel, British Telecom, Ericsson, Motorola, Nokia,
BlackBerry (ex RIM), Siemens, Sony Ericsson, T-Mobile
US

Today
Some major operators
use it
62
GAN Characteristics
Advantages
•
•
Subscribers
•
•
•
•
Operators
•
Disadvantages
Better indoor coverage
No roaming charges on
WiFi when abroad
Single “phone” number,
single device
Seamless handovers
WiFi <-> cellular
•
•
Hassle of initial setup
Higher battery usage
(WiFi enabled)
Increase coverage at
modest cost
Reduce load on macrocells
Re-use of existing
hotspots
•
Extra infrastructure
required
Cost of support to
costumers
•
63
References on Mobile IP







RFC 1701 - Generic Routing Encapsulation (GRE)
RFC 2003 - IP encapsulation within IP
RFC 2004 - Minimal encapsulation within IP
RFC 3024 - Reverse Tunneling for Mobile IP (revised)
RFC 4721 – Mobile IPv4 Challenge/Response Extensions
RFC 5944 – IP Mobility Support for IPv4, Revised
RFC 6275 – Mobility support for IPv6
64
References on HIP









http://www.openhip.org/
RFC 4423 - Host Identity Protocol (HIP) Architecture
RFC 5201 - Host Identity Protocol
RFC 5202 - Using the Encapsulating Security Payload (ESP) Transport
Format with the Host Identity Protocol (HIP)
RFC 5203 - Host Identity Protocol (HIP) Registration Extension
RFC 5204 - Host Identity Protocol (HIP) Rendezvous Extension
RFC 5206 - End-Host Mobility and Multihoming with the Host Identity
Protocol
RFC 5207 – NAT and Firewall Traversal Issues of Host Identity
Protocol (HIP) Communication
RFC 6092 – Basic requirements for IPv6 Customer Edge Routers
65
66