1 / 12

HIP API issues in base spec

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”)

ariane
Download Presentation

HIP API issues in base spec

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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 (miika@iki.fi)

  4. 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

  5. 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?

  6. 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

  7. 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

  8. 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

  9. 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

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

  11. 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

  12. 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

More Related