Skip to main content

IPv6 Host-to-Router Load Sharing
RFC 4311

Revision differences

Document history

Date Rev. By Action
2015-10-14
04 (System) Notify list changed from bob.hinden@nokia.com, brian@innovationslab.net to (None)
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Bill Fenner
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Alex Zinin
2005-12-06
04 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-12-06
04 Amy Vezza [Note]: 'RFC 4311' added by Amy Vezza
2005-11-01
04 (System) RFC published
2005-07-29
04 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-07-06
04 Amy Vezza IESG state changed to Approved-announcement sent
2005-07-06
04 Amy Vezza IESG has approved the document
2005-07-06
04 Amy Vezza Closed "Approve" ballot
2005-07-06
04 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2005-07-05
04 Alex Zinin [Ballot Position Update] Position for Alex Zinin has been changed to No Objection from Discuss by Alex Zinin
2005-07-01
04 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner
2005-06-30
04 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-06-30
04 (System) New version available: draft-ietf-ipv6-host-load-sharing-04.txt
2005-04-06
04 Michelle Cotton IANA Comments:
We understand this document to have no IANA Actions.
2005-04-01
04 (System) Removed from agenda for telechat - 2005-03-31
2005-03-31
04 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2005-03-31
04 Bill Fenner
[Ballot discuss]
I think this should be listed as updating whatever existing RFCs describe the current algorithm ([ND] and [ROUTERSEL], maybe?), so that the RFC …
[Ballot discuss]
I think this should be listed as updating whatever existing RFCs describe the current algorithm ([ND] and [ROUTERSEL], maybe?), so that the RFC Index has a forward pointer from the possibly-bad algorithms.
2005-03-31
04 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to Discuss from No Objection by Bill Fenner
2005-03-31
04 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-03-31
04 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2005-03-31
04 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-03-31
04 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-03-30
04 David Kessens
[Ballot comment]
Comments from the Ops directorate by Pekka Savola (Mar 30 17:47:13 PST 2005):

Basically a good document.  Two medium-level comments:

- [ROUTERSEL] should …
[Ballot comment]
Comments from the Ops directorate by Pekka Savola (Mar 30 17:47:13 PST 2005):

Basically a good document.  Two medium-level comments:

- [ROUTERSEL] should probably be a Normative reference, as the doc
appears to be referring/depending on that behaviour.  The draft in
question is past the IESG, in AD followup so it shouldn't be an issue.

- Introduction says,

"It is typically 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."

  I would s/typically/often/, because whether this is really typical
or not is in the eye of the beholder, and I doubt there's any real
measurement of the desired behaviour out there.
2005-03-30
04 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-03-30
04 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-03-30
04 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-03-29
04 Brian Carpenter
[Ballot comment]
Review comment:

There's one minor nit in
that the [ROUTERSEL] reference needs updating, but that can be resolved by
RFC editor or during …
[Ballot comment]
Review comment:

There's one minor nit in
that the [ROUTERSEL] reference needs updating, but that can be resolved by
RFC editor or during AUTH48.

Regards,
Mary H. Barnes
mary.barnes@nortel.com
2005-03-29
04 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-03-27
04 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2005-03-24
04 Alex Zinin
[Ballot discuss]
I almost pushed "Yes" on this document--it's really a great job.
A discuss'y DISCUSS:

  The load-sharing algorithm suggested in Section 2 can …
[Ballot discuss]
I almost pushed "Yes" on this document--it's really a great job.
A discuss'y DISCUSS:

  The load-sharing algorithm suggested in Section 2 can do better on a larger
  scale if it takes into consideration not only the destination address, but the
  src-dst pair.

  The situation to think about is multiple hosts running the same implementation
  (hence using the same algorithm) and communicating with the same remote
  host(s), e.g. a server (farm). If only dst is fed into the function, traffic
  from different hosts to the same dst will be polarized and will use only one
  router. If src is added, a better distribution can be achieved.
2005-03-24
04 Alex Zinin [Ballot Position Update] New position, Discuss, has been recorded for Alex Zinin by Alex Zinin
2005-03-21
04 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-03-20
04 Margaret Cullen State Changes to IESG Evaluation from Waiting for Writeup by Margaret Wasserman
2005-03-20
04 Margaret Cullen
Submission Questionnaire:

1) Have the chairs personally reviewed this version of the ID and do

  they believe this ID is sufficiently baked to forward …
Submission Questionnaire:

1) Have the chairs personally reviewed this version of the ID and do

  they believe this ID is sufficiently baked to forward to the IESG

  for publication?



Yes



2) Has the document had adequate review from both key WG members and

  key non-WG members? Do you have any concerns about the depth or

  breadth of the reviews that have been performed?



This document has been reviewed by multiple members of the WG.

We do not have any concerns on those reviews.



3) Do you have concerns that the document needs more review from a

  particular (broader) perspective (e.g., security, operational

  complexity, someone familiar with AAA, etc.)?



No



4) Do you have any specific concerns/issues with this document that

  you believe the ADs and/or IESG should be aware of? For example,

  perhaps you are uncomfortable with certain parts of the document,

  or whether there really is a need for it, etc., but at the same

  time these issues have been discussed in the WG and the WG has

  indicated it wishes to advance the document anyway.



No concerns



5) How solid is the WG consensus behind this document?  Does it

  represent the strong concurrence of a few individuals, with others

  being silent, or does the WG as a whole understand and agree with

  it?



There is a strong concurrence among key WG members



6) Has anyone threatened an appeal or otherwise indicated extreme

  discontent?  If so, please summarize what are they upset about.



No known threats



7) Have the chairs verified that the document adheres to _all_ of the

  ID nits?



Yes



- Technical Summary



The original IPv6 conceptual sending algorithm does not do load-

sharing among equivalent IPv6 routers, and suggests schemes which

can be problematic in practice.  This document updates the

conceptual sending algorithm so that traffic to different

destinations can be distributed among routers in an efficient

fashion.



- Working Group Summary



The IPv6 working group has done extensive review of this document and

this document reflects the consensus of the group.



- Protocol Quality



This document has been reviewed by members of the ipv6@ietf.org

mailing list and by the working group chairs.





Regards,

Brian & Bob

IPv6 WG co-chairs
2005-03-20
04 Margaret Cullen Placed on agenda for telechat - 2005-03-31 by Margaret Wasserman
2005-03-20
04 Margaret Cullen [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman
2005-03-20
04 Margaret Cullen Ballot has been issued by Margaret Wasserman
2005-03-20
04 Margaret Cullen Created "Approve" ballot
2005-03-18
04 (System) State has been changed to Waiting for Writeup from In Last Call by system
2005-02-25
04 Amy Vezza Last call sent
2005-02-25
04 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-02-25
04 Margaret Cullen State Changes to Last Call Requested from Publication Requested by Margaret Wasserman
2005-02-25
04 Margaret Cullen Last Call was requested by Margaret Wasserman
2005-02-25
04 (System) Ballot writeup text was added
2005-02-25
04 (System) Last call text was added
2005-02-25
04 (System) Ballot approval text was added
2005-01-18
04 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2004-10-21
03 (System) New version available: draft-ietf-ipv6-host-load-sharing-03.txt
2004-05-05
02 (System) New version available: draft-ietf-ipv6-host-load-sharing-02.txt
2004-02-03
01 (System) New version available: draft-ietf-ipv6-host-load-sharing-01.txt
2002-01-10
00 (System) New version available: draft-ietf-ipv6-host-load-sharing-00.txt