Dave Thaler dthaler@microsoft.com A Comparison of Mobility-Related Protocols: MIP6,SHIM6, and HIP draft-thaler-mobility-comparison-01.txt Dave Thaler dthaler@microsoft.com IETF 66
Goal of this presentation Help those in none of the WGs understand the relationship between them Help those in one WG understand other WGs IETF 66
Disclaimers Only work in the IETF (as WG drafts and RFCs) has been considered There are individual submissions and IRTF drafts in addition This is a snapshot in time, as of beginning of June 2006 This is a moving target Only MIP6, SHIM6, and HIP have been considered so far Other mobility-related protocols do exist (NEMO, SCTP, NETLMM, MOBIKE, etc.) Points of comparison derived from union of the three problem statements IETF 66
Terminology Name: A DNS fully-qualified domain name Upper-layer Identifier (ULID): Address used above the mobility/multihoming layer MIP6: “Home Address” SHIM6: “ULID” HIP: “Host Identity Tag (HIT)” Locator: Address used below the mobility/multihoming layer MIP6: “Care-of Address” SHIM6 & HIP: “Locator” IETF 66
Extension Header Order Each protocol defines headers to go in data packets, and defines where they have to go A hypothetical data packet with all of them, plus other headers, would look like this: IPv6 Hdr HbH Opts Type 2 Rtg Hdr DstOpts (HoA) SHIM6 PEH Frag Hdr ESP (HIP) Payload Mobile IPv6 SHIM6 HIP This leads to a natural layering model… IETF 66
Fragmentation/reassembly Layering Transport layer IPsec + HIP sub-layer Fragmentation/reassembly Network Layer SHIM6 sub-layer MIP6 sub-layer Routing sub-layer Link layer IETF 66
Feature Comparison 1/2 MIP SHIM6 HIP Preserve established connections Yes Support both ends moving simultaneously Only within known set Span outages No Resolve name to locators immediately after move IETF 66
Feature Comparison 2/2 MIP SHIM6 HIP Support referrals Yes Only by name Stable addresses Assumed Non-routable Support load spreading (monami6) Multicast sourcing support Not mobile No IETF 66
Efficiency Considerations MIP SHIM6 HIP Per-packet overhead (bytes) 0 if both home / 20/40 if src away + 24 if dest away 0 normally / 8 if moved 0 + IPsec transport mode (~18-29) Connect overhead (messages) 0 if home / 6 if away 0 + 4 for IPsec key neg Locator change overhead (messages) 2 to update HA + 6 to update peer 4 to update peer 3 to update RVS + 3 to update peer IETF 66
Deployment Considerations MIP SHIM6 HIP One-end benefit Yes No Typical deployment dependencies Home agent None Rendezvous Server, New RR, IPsec For the full security benefit of HIP, DNSSec is also needed However, without it, it’s no worse than the others IETF 66
Security Considerations MIP SHIM6 HIP Control message auth check: Minimum On path On path + new locator of same node Cryptographic Maximum Data security Optional Required IETF 66
Questions? IETF 66