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

1
88 Addressing for IPv6 End to End
Multihomingltdraft-ohta-multi6-8plus8-00.txtgt

• Masataka Ohta
• Tokyo Institute of Technology
• mohta_at_necom830.hpcl.titech.ac.jp

2
88 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 88
  addressing
• hopefully not with any packet exchange
• EUI-64 based IPv6 unicast address format reserves
  group bit
• can be used to enable 88

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