Browse Prior Art Database

IPv6 Host-to-Router Load Sharing (RFC4311)

IP.com Disclosure Number: IPCOM000132087D
Original Publication Date: 2005-Nov-01
Included in the Prior Art Database: 2019-Feb-14
Document File: 5 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Hinden: AUTHOR [+1]

Related Documents

10.17487/RFC4311: DOI

Abstract

The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. [STANDARDS-TRACK]

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

Network Working Group R. Hinden Request for Comments: 4311 Nokia Updates: 2461 D. Thaler Category: Standards Track Microsoft November 2005

IPv6 Host-to-Router Load Sharing

Status of This Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2005).

Abstract

The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion.

1. Introduction

In the conceptual sending algorithm in [ND] and in the optional extension in [ROUTERSEL], a next hop is chosen when no destination cache entry exists for an off-link destination or when communication through an existing router is failing. Normally, a router is selected the first time traffic is sent to a specific destination IP address. Subsequent traffic to the same destination address continues to use the same router unless there is some reason to change to a different router (e.g., a redirect message is received, or the router is found to be unreachable).

In addition, as described in [ADDRSEL], the choice of next hop may also affect the choice of source address, and hence indirectly (and to a lesser extent) may affect the router used for inbound traffic as well.

Hinden & Thaler Standards Track [Page 1]

RFC 4311 IPv6 Host-to-Router Load Sharing November 2005

In both the base sending algorithm and in the optional extension, sometimes a host has a choice of multiple equivalent routers for a destination. That is, all other factors are equal and a host must break a tie via some implementation-specific means.

It is often desirable when there is more than one equivalent router that hosts distribute their outgoing traffic among these routers. This shares the load among multiple routers and provides better performance for the host’s traffic.

On the other hand, load sharing can be undesirable in situations where sufficient capacity is available through a single router and the traffic patterns could be more predictable by using a single router; in particular, this helps to diagnose connectivity problems beyond the first-hop routers.

[ND] does not require any particular behavior in this respect. It specifies that an implementation may always choose the same router (e.g., the first in the list) or may cycle through the routers in a round-robin manner. Both of these suggestions are problematic.

Clearly, always choosing the same router does not provide load sharing. Some problems with load sharing using naive tie-breaking technique...

Processing...
Loading...