Introduction to multihoming, address selection, failure detection, and recovery

1
Introduction to multihoming, address selection,
failure detection, and recovery

• Jari Arkko
• Ericsson Research NomadicLab
• jari.arkko_at_ericsson.com
• Partially based on
• draft-arkko-multi6dt-failure-detection-00.txt
• and work done by the multi6 design team

2
Goals...

• Introduce a few potentially useful terms and
  concepts
• Overview of IETF mechanisms that affect
  multihoming decisions
• Introduce some related IETF work
• Suggest a few design principles

3
Multihoming Basics

• Theres more than one path for traffic
• Typically, multiple addresses for some
  participants
• Multiple addresses on one or both end hosts
• Observations
• Nodes should know about their own addresses
• And learn about the peers addresses over the
  MOBIKE protocol
• Need to know the peers addresses before a
  failure -- otherwise you might not be able to
  communicate with the peer

4
Addresses -- Where Do They Come From and Where Do
They Go To?

• Addresses come from other parts of the stack --
  the IP layer
• The addresses are typically discovered through
  protocols such as DHCP or ND
• Addresses are not trivial -- DAD,
  valid/deprecated, ...
• Address allocation can be secure (but security
  often not turned on)
• Addresses are taken away by the same mechanisms
• It is necessary for MOBIKE to believe what
  these other parts of the stack say

5
A Few Address-Related Definitions

• Available address
• Address is assigned to an interface
• The address is valid (in IPv6) and has completed
  uniqueness tests
• Locally operational address
• Address is available
• L2 green light is on
• Default router is reachable (IPv6 NUD)

6
Related IETF Work

• An obvious set of configuration modules and
  protocols that handle address assignment and
  deletion and other related tasks
• A growing body of work for improving the
  characteristics related to changing connectivity
  at the lower layer
• DNA WG draft-ietf-dna-goals-03.txt
• DHC WG draft-ietf-dhc-dna-ipv4-09.txt
• NATted addresses are discovered in IKE using
  NAT-T and for some other applications STUN/ICE
  are used

7
Are Two Locally Operational Addresses Enough?
8
The Definition of an Address Pair

• Address pair
• A pair of addresses (src, dst) used in
  communications between two peers
• Operational address pair
• Both addresses are locally operational
• Traffic flows when the pair is used
• Note 1 due to NATs, firewalls, etc. the
  operational status may depend on the type of
  traffic (IKEv2, HTTP etc)
• Note 2 there can be many address pairs if both
  peers have multiple addresses -- and hard to know
  a priori which ones work

9
Selecting an Address

• How do we know there is a problem?
• The address went away (certain)
• DPD failed (certainbut might be a transient
  problem)
• Lack of TCP progress, ICMP, (hmm...)
• Picking another pair
• Existing protocols SCTP, STUN/ICE
• Multi6, hip, and mobike looking at this too
• Probable that the solutions need to be integrated
  relatively closely to what is being done, e.g.,
  SCTP or IKEv2

10
Some Suggested Design Principles

• MOBIKE should not venture in to the area of the
  address allocation or other local connectivity
  mechanisms
• We shall not reinvent DHCP or ND
• But it is OK to get information from these
• Generally, it is necessary to believe these other
  modules
• Local connectivity ! global connectivity
• Both need to be addressed
• Deal only with the bidirectional connectivity
  case
• Finding an operational address pair can result in
  a combinatorial explosion -- employ exponential
  backoff
• Exact search order is implementation-dependent