IPv6 Stateless Address Autoconfiguration
RFC 4862
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
08 | (System) | Notify list changed from ipv6-chairs@ietf.org to (None) |
2012-08-22 |
08 | (System) | post-migration administrative database adjustment to the No Objection position for Allison Mankin |
2012-08-22 |
08 | (System) | post-migration administrative database adjustment to the No Objection position for Sam Hartman |
2012-08-22 |
08 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2007-09-28 |
08 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2007-09-28 |
08 | Amy Vezza | [Note]: 'RFC 4862' added by Amy Vezza |
2007-09-24 |
08 | (System) | RFC published |
2006-08-23 |
08 | Jari Arkko | State Change Notice email list have been change to ipv6-chairs@tools.ietf.org from bob.hinden@nokia.com, brian@innovationslab.net |
2005-11-10 |
08 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2005-11-07 |
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
2005-11-07 |
08 | Amy Vezza | IESG has approved the document |
2005-11-07 |
08 | Amy Vezza | Closed "Approve" ballot |
2005-11-06 |
08 | Margaret Cullen | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman |
2005-10-05 |
08 | Allison Mankin | [Ballot comment] My Discuss was not addressed at all - I believe that the WG ignored the spirit of the implementation report requirement - my … [Ballot comment] My Discuss was not addressed at all - I believe that the WG ignored the spirit of the implementation report requirement - my Discuss said that we should know that there are multiple implementations that have handled the significant changes in the recycling of this Draft Standard. The group apparently refused to update its implementation report, but I believe did not respond on this. I did not intend to conduct a pocket veto, and I do not believe that my objection should have been played this way, if that's what happened. Clearing rather than punish the technical protocol for its context. I assume the interoperability testers are somewhere out in the world (IETF is not in this business). |
2005-10-04 |
08 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Discuss by Allison Mankin |
2005-09-14 |
08 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2005-05-12 |
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-05-12 |
08 | (System) | New version available: draft-ietf-ipv6-rfc2462bis-08.txt |
2005-03-04 |
08 | (System) | Removed from agenda for telechat - 2005-03-03 |
2005-03-03 |
08 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2005-03-03 |
08 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Amy Vezza |
2005-03-03 |
08 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman |
2005-03-03 |
08 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2005-03-03 |
08 | Allison Mankin | [Ballot discuss] 1. No updated implementation report; I'd like to see reporting in there of the basis for the dropping of the Managed … [Ballot discuss] 1. No updated implementation report; I'd like to see reporting in there of the basis for the dropping of the Managed bit, which is stated in the draft as an implementation result. It's a good simplification, it sounds like, but documenting this in the report would be good. Didn't the reading of 2026 come out updated implementation reports for recycling DS's? 2. There is a lot of normative dependency on the recycling DS of Neighbory Discovery which not even in the tracker yet, so are there some instabilities? 3. Was there an analysis of the configuration consistency rule (section 5.6) of acceptng the most recent information, while trying to secure both DHCPv6 and ND/addrconf (SEND)? |
2005-03-03 |
08 | Allison Mankin | [Ballot discuss] 1. No updated implementation report; I'd like to see reporting in there of the basis for the dropping of the Managed … [Ballot discuss] 1. No updated implementation report; I'd like to see reporting in there of the basis for the dropping of the Managed bit, which is stated in the draft as an implementation result. It's a good simplification, it sounds like, but documenting this in the report would be good. Didn't the reading of 2026 come out updated implementation reports for recycling DS's? 2. There is a lot of normative dependency on the recycling DS of Neighbory Discovery which not even in the tracker yet, so are there some instabilities? 3. Was there an analysis of the configuration consistency rule (section 5.6) of acceptng the most recent information, while trying to secure both DHCPv6 and ND/addrconf (SEND)? |
2005-03-03 |
08 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to Discuss from No Objection by Allison Mankin |
2005-03-03 |
08 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Undefined by Allison Mankin |
2005-03-03 |
08 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2005-03-03 |
08 | Allison Mankin | [Ballot Position Update] New position, Undefined, has been recorded for Allison Mankin by Allison Mankin |
2005-03-03 |
08 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2005-03-02 |
08 | Russ Housley | [Ballot discuss] RFC 3756 says that IPsec really does not work for neighbor discovery. Even if it does work in some cases, there is … [Ballot discuss] RFC 3756 says that IPsec really does not work for neighbor discovery. Even if it does work in some cases, there is not enough detail in this document to say how to use it. SEND is the answer, of course. However, this document cannot have a normative reference to SEND because this document is going for publication as Draft Standard. My recommendation is to delete the text regarding the use of IPsec and replace it with an Informative reference to SEND. I think this is better than misleading the reader. |
2005-03-02 |
08 | Russ Housley | [Ballot comment] I suggest adding another event to section 5.3. Consider an event that indicates that the physical network connectivity may have changed. … [Ballot comment] I suggest adding another event to section 5.3. Consider an event that indicates that the physical network connectivity may have changed. Such events include a carrier down/carrier sequence on an Ethernet NIC, a change of SSID on an 802.11 network, or waking up from a "sleep" period. |
2005-03-02 |
08 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
2005-03-01 |
08 | Sam Hartman | [Ballot discuss] Steve Bellovin pointed out the following text in the security considerations section: >These attacks can be addressed by requiring > that Neighbor Discovery … [Ballot discuss] Steve Bellovin pointed out the following text in the security considerations section: >These attacks can be addressed by requiring > that Neighbor Discovery packets be authenticated with IP security > [RFC2402]. However, it should be noted that [RFC3756] points out the > use of IP security is not always feasible depending on network > environments. IPsec really isn't a good fit for neighbor discovery; SEND is the solution we have come up with to solve these problems. I realize we cannot have a normative reference to SEND from this specification. An informative reference might be acceptable. Either way I request that the text on IPsec be deleted. AT best it will lead people down the wrong path. |
2005-03-01 |
08 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded for Sam Hartman by Sam Hartman |
2005-02-28 |
08 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2005-02-26 |
08 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
2005-02-26 |
08 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
2005-02-26 |
08 | Margaret Cullen | Created "Approve" ballot |
2005-02-25 |
08 | Margaret Cullen | State Changes to IESG Evaluation from Waiting for Writeup by Margaret Wasserman |
2005-02-25 |
08 | Margaret Cullen | Placed on agenda for telechat - 2005-03-03 by Margaret Wasserman |
2005-01-31 |
08 | Michelle Cotton | IANA Last Call Comments: We understand this document to have NO IANA Actions. |
2005-01-28 |
08 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2005-01-14 |
08 | Amy Vezza | Last call sent |
2005-01-14 |
08 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2005-01-13 |
08 | Margaret Cullen | Last Call was requested by Margaret Wasserman |
2005-01-13 |
08 | Margaret Cullen | State Changes to Last Call Requested from IESG Evaluation by Margaret Wasserman |
2005-01-13 |
08 | (System) | Ballot writeup text was added |
2005-01-13 |
08 | (System) | Last call text was added |
2005-01-13 |
08 | (System) | Ballot approval text was added |
2005-01-13 |
08 | Margaret Cullen | State Changes to IESG Evaluation from AD Evaluation::AD Followup by Margaret Wasserman |
2004-12-28 |
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-12-28 |
07 | (System) | New version available: draft-ietf-ipv6-rfc2462bis-07.txt |
2004-12-05 |
08 | Margaret Cullen | Send follow-up message to Jinmei to check status. |
2004-10-06 |
08 | Margaret Cullen | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Margaret Wasserman |
2004-10-06 |
08 | Margaret Cullen | AD REVIEW COMMENTS SENT TO AUTHOR & IPV6 LIST: Hi Jinmei, I finished my AD review of draft-ietf-ipv6-rfc2462bis-06.txt. I have several comments on this document … AD REVIEW COMMENTS SENT TO AUTHOR & IPV6 LIST: Hi Jinmei, I finished my AD review of draft-ietf-ipv6-rfc2462bis-06.txt. I have several comments on this document that I believe should be resolved before this document is sent to IETF Last Call for publication as a Draft Standard. All of my comments are included below, but my most serious concerns are: (1) Having decided that "the stateful configuration" mechanism is DHCPv6, I don't think that there is a reason to maintain the awkward and confusing wording about "the stateful mechanism" in many places. I've pointed out the worst cases, but there are many others. I know that this is largely an editorial concern, but the awkwardness and lack of clarity are bad enough in some places (see below) that I consider this a blocking problem for publication at DS. (2) I am not comfortable with the idea that we would punt the interpretation of the M & O bits to a "separate document" with no reference. I believe that information about how to interpret these bits is essential to implementing IPv6 address autoconfiguration. See below for the specific text that concerns me. I'd be interested in your feedback on these issues, as well as on the other more minor issues I've noted below. I've cc:ed the IPv6 WG on this message, and other IPv6 folks should also feel free to respond, especially if you think that I'm mistaken about something. Margaret --- My comments are in-line, marked with ">>" Abstract This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information can be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they can be obtained through the stateless mechanism, the stateful mechanism, or both. >> whether they can be obtained through stateless autoconfiguration, the Dynamic Host Configuration Protocol (DHCP) or both? This document defines the process for generating a link-local address, the process for generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified in RFC 3315; an alternative way of using the stateful protocol to deliver 'other information' only is specified in RFC 3736. >> I'd move the whole last sentence to an introduction and take it out of the abstract. Since we can't have references in an abstract, I think it is useless, anyway. 1. INTRODUCTION This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6). The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information can be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they can be obtained through the stateless mechanism, the stateful mechanism, or both. >> s/the stateful mechanism/DHCP This document defines the process for generating a link-local address, the process for generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol is specified in [RFC3315] and [RFC3736]. >> s/the stateful protocol/DHCP IPv6 defines both a stateful and stateless address autoconfiguration mechanism. Stateless autoconfiguration requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link. In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a Dynamic Host Configuration Protocol (DHCPv6) server. Servers maintain a database that keeps track of which addresses have been assigned to which hosts. The stateful autoconfiguration protocol allows hosts to obtain addresses, other configuration information or both from a server. Stateless and stateful autoconfiguration complement each other. For example, a host can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information. To obtain other configuration information without configuring addresses in the stateful autoconfiguration model, a subset of DHCPv6 [RFC3736] will be used. While the model is called "stateful" here in order to highlight the contrast to the stateless protocol defined in this document, the intended protocol is also defined to work in a stateless fashion. This is based on a result, through operational experiments, that all known "other" configuration information can be managed by a stateless server, that is, a server that does not maintain state of each client that the server provides with the configuration information. >> This is the part that I consider to be quite awkward, particularly the vague references to operational experiments that aren't documented or referenced here. If you switch to just referring to DHCP, the preceeding three paragraphs can be substantially simplified. I also thin it is unnecessary to say so much about how DHCP works -- that is the subject of other document. There are many other places where the text would be much clearer if DHCP (or DHCPv6) were used instead of "the stateful mechanism", but I will not mark them all. The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable. The stateful approach is used when a site requires tighter control over exact address assignments. Both stateful and stateless address autoconfiguration may be used simultaneously. The site administrator specifies which type of autoconfiguration is available through the setting of appropriate fields in Router Advertisement messages [I-D.ietf-ipv6-2461bis]. >> Given this normative reference, would it make sense to hold 2462bis until 2461bis is completed and send them forward together? Otherwise, this will just block in the RFC Editor, and we won't have the ability to change it again if we discover issue while finishing the 2461 update. Thoughts? 2. TERMINOLOGY >> Is this terminology section intended to be in logical order? Is there a reason to prefer this order over an alphabetical listing? Nodes (both hosts and routers) begin the autoconfiguration process by generating a link-local address for the interface. A link-local address is formed by appending the interface's identifier to the well-known link-local prefix. >> I think that there should be a reference to the addressing architecture or the scoped address architecture here... Something that tells me how I actually create a link-local address. A "managed address configuration (M)" flag indicates whether hosts can use stateful autoconfiguration [RFC3315] to obtain addresses. An "other stateful configuration (O)" flag indicates whether hosts can use stateful autoconfiguration [RFC3736] to obtain additional information (excluding addresses). The details of how a host may use the M flag, including any use of the "on" and "off" transitions for this flag, to control the use of the stateful protocol for address assignment will be described in a separate document. Similarly, the details of how a host may use the O flag, including any use of the "on" and "off" transitions for this flag, to control the use of the stateful protocol for getting other configuration information will be described in a separate document. However a host uses the M and O flags, and local configuration to control autoconfiguration, the default setting will result in received Router Advertisements being processed for stateless address autoconfiguration. >> I don't think it is okay to publish a DS that leaves important implementation details to a "separate document". Has the separate document been published? If so, it needs to be normatively referenced here. Router Advertisements also contain zero or more Prefix Information options that contain information used by stateless address autoconfiguration to generate global addresses. It should be noted that the stateless and stateful address autoconfiguration fields in Router Advertisements are processed independently of one another, and a host may use both stateful and stateless address autoconfiguration simultaneously. One Prefix Information option field, the "autonomous address-configuration flag", indicates whether or not the option even applies to stateless autoconfiguration. If it does, additional option fields contain a subnet prefix together with lifetime values indicating how long addresses created from the prefix remain preferred and valid. >> What happens if the value of the "autonomous address-configuration flag" changes over time? For safety, all addresses must be tested for uniqueness prior to their assignment to an interface. The test should individually be performed on all addresses obtained manually, via stateless address autoconfiguration, or via stateful address autoconfiguration. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag. >> I am not sure how the last sentence is consistent with the must in the first sentence. Change the must in the first sentence to a should? |
2004-10-03 |
08 | Margaret Cullen | State Changes to AD Evaluation from Publication Requested by Margaret Wasserman |
2004-09-24 |
08 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2004-09-03 |
06 | (System) | New version available: draft-ietf-ipv6-rfc2462bis-06.txt |
2004-08-12 |
05 | (System) | New version available: draft-ietf-ipv6-rfc2462bis-05.txt |
2004-08-11 |
04 | (System) | New version available: draft-ietf-ipv6-rfc2462bis-04.txt |
2004-07-21 |
03 | (System) | New version available: draft-ietf-ipv6-rfc2462bis-03.txt |
2004-06-17 |
02 | (System) | New version available: draft-ietf-ipv6-rfc2462bis-02.txt |
2004-06-15 |
01 | (System) | New version available: draft-ietf-ipv6-rfc2462bis-01.txt |
2004-02-10 |
00 | (System) | New version available: draft-ietf-ipv6-rfc2462bis-00.txt |