1 / 10

8+8 Addressing for IPv6 End to End Multihoming <draft-ohta-multi6-8plus8-00.txt>

8+8 Addressing for IPv6 End to End Multihoming <draft-ohta-multi6-8plus8-00.txt>. Masataka Ohta Tokyo Institute of Technology mohta@necom830.hpcl.titech.ac.jp. 8+8 Addressing. Addresses are constructed from 8 byte locators mostly ignored by ULPs 8 byte IDs to identify ULP entities

mavis
Download Presentation

8+8 Addressing for IPv6 End to End Multihoming <draft-ohta-multi6-8plus8-00.txt>

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. 8+8 Addressing for IPv6 End to End Multihoming<draft-ohta-multi6-8plus8-00.txt> Masataka Ohta Tokyo Institute of Technology mohta@necom830.hpcl.titech.ac.jp

  2. 8+8 Addressing • Addresses are constructed from • 8 byte locators mostly ignored by ULPs • 8 byte IDs to identify ULP entities • For multihoming with multiple addresses • The Internetworking layer is stateless and can not hold session information • as exemplified by PMTUD gotcha • no change on the Internetworking layer • Interoperability with legacy v6 is an issue

  3. Leagacy IPv6 and EUI-64 based IPv6 unicast address • Transport layer needs to know when to support 8+8 addressing • hopefully not with any packet exchange • EUI-64 based IPv6 unicast address format reserves group bit • can be used to enable 8+8

  4. ID Space Structure • IDs may be derived from locators • IDs have structure corresponding to routing hierarchy • IDs may be used anywhere including sites outside of a site from where the IDs are derived • May be useful for temporary ID for privacy • IDs may be assigned like domain names • without trademark issues

  5. Destination Locator Selection • Choose randomly • Consult the global routing table • site administrators can tell its preference as some metric for load balancing

  6. Source Locator Selection • Not an issue • is an issue of a peer as a destination locator selection • Is an issue for ingress filtering • let routing protocols carry the proper source locator

  7. IP Mobility • Not an Issue of M6 • IP mobility may be improved using IDs

  8. TCP • Have mechanism to tell locator set to its peer • MA (multi address) option is provided

  9. DNS • Works as is • already support multiple addresses of nameservers

  10. Assessment Against RFC3582 • Have all the desirable properties

More Related