Browse Prior Art Database

Things Multihoming in IPv6 (MULTI6) Developers Should Think About (RFC4219)

IP.com Disclosure Number: IPCOM000130591D
Original Publication Date: 2005-Oct-01
Included in the Prior Art Database: 2019-Feb-14
Document File: 12 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Lear: AUTHOR

Related Documents

10.17487/RFC4219: DOI

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. This memo provides information for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 14% of the total text.

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

Processing...
Loading...