Things Multihoming in IPv6 (MULTI6) Developers Should Think About
RFC 4219

Document Type RFC - Informational (October 2005; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 4219 (Informational)
Telechat date
Responsible AD David Kessens
Send notices to brc@zurich.ibm.com, kurtis@kurtis.pp.se
Network Working Group                                            E. Lear
Request for Comments: 4219                                 Cisco Systems
Category: Informational                                     October 2005

   Things Multihoming in IPv6 (MULTI6) Developers Should Think About

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document specifies a set of questions that authors should be
   prepared to answer as part of a solution to multihoming with IPv6.
   The questions do not assume that multihoming is the only problem of
   interest, nor do they demand a more general solution.

Table of Contents

   1. Introduction ....................................................3
      1.1. Reading this Document ......................................3
   2. On the Wire Behavior ............................................4
      2.1. How will your solution solve the multihoming problem? ......4
      2.2. At what layer is your solution applied, and how? ...........4
      2.3. Why is the layer you chose the correct one? ................4
      2.4. Does your solution address mobility? .......................4
      2.5. Does your solution expand the size of an IP packet? ........4
      2.6. Will your solution add additional latency? .................4
      2.7. Can multihoming capabilities be negotiated
           end-to-end during a ........................................4
      2.8. Do you change the way fragmenting is handled? ..............5
      2.9. Are there any layer 2 implications to your proposal? .......5
   3. Identifiers and Locators ........................................5
      3.1. Uniqueness .................................................5
      3.2. Does your solution provide for a split between
           identifiers and ............................................5
      3.3. What is the lifetime of a binding from an
           identifier to a locator? ...................................5
      3.4. How is the binding updated? ................................5
      3.5. How does a host know its identity? .........................5
      3.6. Can a host have multiple identifiers? ......................5

Lear                         Informational                      [Page 1]
RFC 4219             MULTI6 Solution Questionnaire          October 2005

      3.7. If you have separate locators and identifiers, how
           will they be ...............................................5
      3.8. Does your solution create an alternate "DNS-like"
           service? ...................................................5
      3.9. Please describe authentication/authorization ...............6
      3.10. Is your mechanism hierarchical? ...........................6
      3.11. Middlebox interactions ....................................6
      3.12. Are there any implications for scoped addressing? .........6
   4. Routing System Interactions .....................................6
      4.1. Does your solution change existing aggregation methods? ....6
      4.2. Does the solution solve traffic engineering requirements? ..7
      4.3. Does the solution offer ways for the site to manage
           its traffic ................................................7
      4.4. If you introduce any new name spaces, do they
           require aggregation? .......................................7
      4.5. Does your solution interact with Autonomous System
           numbering? .................................................7
      4.6. Are there any changes to ICMP error semantics? .............7
   5. Name Service Interactions .......................................7
      5.1. Please explain the relationship of your solution to DNS ....7
      5.2. Please explain interactions with "2-faced" DNS .............7
      5.3. Does your solution require centralized registration? .......8
      5.4. Have you checked for DNS circular dependencies? ............8
      5.5. What if a DNS server itself is multihomed? .................8
      5.6. What additional load will be placed on DNS servers? ........8
      5.7. Any upstream provider support required? ....................8
      5.8. How do you debug connectivity? .............................8
   6. Application Concerns and Backward Compatibility .................8
      6.1. What application/API changes are needed? ...................8
      6.2. Is this solution backward compatible with "old" IP
           version 6? .................................................9
      6.3. Is your solution backward compatible with IPv4? ............9
      6.4. Can IPv4 devices take advantage of this solution? ..........9
Show full document text