HIP API issues in base spec Tom Henderson IETF-59, March 3, 2004

Background How do applications use HIP-enabled stacks? –IPv4 vs. IPv6 –legacy API vs HIP-enabled API –resolver semantics –policy choices (e.g., “try to use HIP” vs “require HIP”) –how to pass host identities to kernel space via socket calls? –reverse lookups for HITs Many of these issues outside base spec scope

Goal today HIP base spec is concerned with bits on wire –planned for experimental RFC –API documents are informational only Need to resolve issues in base spec with respect to interoperability only –base protocol and the application bits on wire Other issues for further study –See Miika Komu’s work

HIP-aware applications should make use of HIP API and HIP resolver –pass HITs and/or HIs across socket interface –use HITs instead of IPv6 addresses in application data stream –stacks should deal with unresolved HITs somehow HIP-aware applications are internally based on IPv6 data structures

Non-HIP-aware IPv6 apps Base spec issue: Application level data stream in a HIP ESP envelope (MUST|SHOULD|Don’t care) use HITs instead of IPv6 addresses –suggest “Don’t care” –both situations should be handled (different semantics) Research issue: Should resolvers return HITs instead of IPv6 addresses to these apps?

Case 1: Use of IPv6 addresses connect(ipv6) has semantics: “I want to talk to the host currently located at ipv6” Kernel may invoke HIP to the destination based on local policy rules –use opportunistic HIP –retry using IPv6 if HIP exchange fails AND policy allows non-HIP communication –application data stream contains IPv6 addresses

Case 2: Use of HITs connect(HIT) has semantics: “I want to talk to the host identified by HIT” Kernel must invoke HIP to the destination –do not use opportunistic HIP –do not retry using IPv6 if HIP exchange fails –to find locators, kernel must either perform local HI/locator lookup, do reverse lookup based on HIT, or return “Destination unreachable” –application data stream carries HITs in the IPv6 data structures

Case 3: Mixed Server app binds to HIT, client connects to IPv6 address –server accepts connection based on policy for accepting opportunistic HIP –may allow a subsequent server-based referral to escape ESP in some cases Server app binds to IPv6, client connects to HIT –connection could be rejected if it arrives to a different IPv6 address (policy issue) –not a problem in application data stream

Non-HIP-aware IPv4 apps Base spec issue: Application level data stream in a HIP ESP envelope (MUST|SHOULD|Don’t care) use LSIs instead of IPv4 addresses –again, suggest “Don’t care”-- same as IPv6 Lingering issue: LSI collisions

LSI collision problem caused by two peers who have same LSIs –intermittent case, but not statistically impossible HITs different LSI’s equal Ambiguity at socket interface here e.g. FTP server

LSI collision issue options: –existing exchange in I2/R2 not really workable –lightweight exchange performed during DNS resolution to agree on LSIs: “I0/R0” –application NAT if there is an LSI collision

Base spec recommendations Remove LSIs from HIP protocol messages –keep defined as 1.x.x.x where x.x.x corresponds to low order 24 bits of HIP Include brief section summarizing the use and semantics of LSIs and HITs in socket calls and application data streams –right after section on TCP/UDP checksums –recommend NAT if there is an LSI collision Remove Appendix A from draft