Neighbor Discovery support for Multi-home Multi-prefix
draft-vv-6man-nd-support-mhmp-02
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Eduard V , Paolo Volpato | ||
| Last updated | 2023-09-27 (Latest revision 2023-03-26) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Multi-home Multi-prefix (MHMP) IPv6 environment is the norm for businesses that need to have uplink resiliency. Several solutions have been already discussed and proposed to address MHMP and how it can be enabled in different network contexts. This draft looks at MHMP from the perspective of Neighbour Discovery Protocols (NDP). For any considered destination, the MHMP challenge may be split into 3 sub-challenges (important to solve in the below order): 1) the host should choose the proper source address for the packet, 2) the host should choose the best default router as the next hop, 3) site topology may be complicated and may need the source routing through the site. This draft is concerned with the solution for the first two problems that need improvement for the ND (RFC 4861) SLAAC (RFC 4862) and Default Address Selection (RFC 6724). The last problem is considered as properly discussed by Multihoming in Enterprise (RFC 8678).
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)