Host Address Availability Recommendations
draft-ietf-v6ops-host-addr-availability-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-07-20
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-07-14
|
07 | Jean Mahoney | Closed request for Telechat review by GENART with state 'No Response' |
2016-06-27
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-06-08
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-05-27
|
07 | (System) | RFC Editor state changed to EDIT |
2016-05-27
|
07 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2016-05-27
|
07 | (System) | Announcement was received by RFC Editor |
2016-05-27
|
07 | (System) | IANA Action state changed to No IC from In Progress |
2016-05-27
|
07 | (System) | IANA Action state changed to In Progress |
2016-05-27
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2016-05-27
|
07 | Amy Vezza | IESG has approved the document |
2016-05-27
|
07 | Amy Vezza | Closed "Approve" ballot |
2016-05-27
|
07 | Amy Vezza | Ballot writeup was changed |
2016-05-27
|
07 | Amy Vezza | Ballot approval text was generated |
2016-05-27
|
07 | Joel Jaeggli | revved - send |
2016-05-27
|
07 | Joel Jaeggli | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2016-05-25
|
07 | Lorenzo Colitti | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2016-05-25
|
07 | Lorenzo Colitti | New version available: draft-ietf-v6ops-host-addr-availability-07.txt |
2016-05-12
|
06 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2016-05-09
|
06 | Gunter Van de Velde | Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Victor Kuarsingh. |
2016-05-05
|
06 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2016-05-04
|
06 | Jari Arkko | [Ballot comment] I have followed the discussion between Roni Even (Gen-ART reviewer) and Lorenzo: > The intent here is to say that while the DHCPv6 … [Ballot comment] I have followed the discussion between Roni Even (Gen-ART reviewer) and Lorenzo: > The intent here is to say that while the DHCPv6 PD RFC uses the words > "requesting router" to denote the DHCP client, is nothing in DHCPv6 PD > itself that requires the PD client to be a router (where, in IPv6, the term > "router" is defined in RFC2460). > So - even though the DHCPv6 PD RFC uses the term "requesting router", a > host can use DHCPv6 PD to receive a prefix as well. The host can pick some > addresses for that prefix for its own use, originate/terminate packets on > those addresses, and not forward packets addressed to any of the other > addresses in the prefix. Personally, I think it would perhaps useful to consider a slight reformulation of the text, given that for things like tethering or virtual machines, hosts essentially become routers. |
2016-05-04
|
06 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2016-05-04
|
06 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to Yes from No Objection |
2016-05-04
|
06 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2016-05-04
|
06 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2016-05-04
|
06 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from No Objection |
2016-05-04
|
06 | Stephen Farrell | [Ballot comment] (I'm getting a bit outside my area of expertise here, but since I've been playing about with IPv6 recently and am not shy … [Ballot comment] (I'm getting a bit outside my area of expertise here, but since I've been playing about with IPv6 recently and am not shy about asking silly questions... :-) - I think you're missing one other reason why people allocate /128's - in a hosting/VPS environment, the hoster might want to avoid VPS's that originate spam using many different source addresses over time so as to attempt to avoid IP address based (bad) reputation accruing to their outbound spam. Personally, I think associating such reputation scores with IPv6 prefixes or addresses is a bit dodgy, but this is I think something that is done in the wild, (no idea how frequently) so would be worth a mention. If you have good arguments as to why such a scheme is a bad idea, that'd be good to include as well. - I was a bit surprised to not see any mention here of ULAs. I've seen one DHCPv6 setup where my laptop was assigned a ULA with a very long lease in the hope of always having that connectivity to local systems that aren't all on the link. But having that plus real global addresses caused glitches as (I think) my OS (ubuntu) wasn't sure which of the addresses to use as the source for what. While I didn't explore what was going on there (I just zapped the lease:-), do you need to say how to handle cases where one has both real global and ULAs on an interface? - I would have liked if you had said that, other things being equal, OSes SHOULD prefer to use privacy addresses as the source address or as a default. Is there a reason to not say that? (Just wondering, I'm not trying to strongly argue that you do.) |
2016-05-04
|
06 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2016-05-03
|
06 | Suresh Krishnan | [Ballot comment] Section 3: * What is the term ePDG being used here? Can you please add a reference? The well known term in mobile … [Ballot comment] Section 3: * What is the term ePDG being used here? Can you please add a reference? The well known term in mobile networks is Evolved Packet Data Gateway that is used for IPsec tunnel termination. That does not seem to make sense here. * Maybe worth adding a reference to RFC7278 (64share) here as an example for "Extending the network (e.g., "tethering")." s/which is only available in 3GPP release 10/which is only available in 3GPP release 10 onwards/ Section 4: It is not clear what this bullet means. Can you clarify? " o Uncertainty, because it is not known in advance if a particular operation function will be available." |
2016-05-03
|
06 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2016-05-03
|
06 | Terry Manderson | [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson |
2016-05-03
|
06 | Ben Campbell | [Ballot comment] While I am afraid the NAT66 cats are forever out of their bag, I am still glad to see this draft. Section 7: … [Ballot comment] While I am afraid the NAT66 cats are forever out of their bag, I am still glad to see this draft. Section 7: I _think_ the point of this section is to suggest that we cannot reasonably estimate an upper limit. But if it says that explicitly, I missed it. (I fear a careless reader will walk away thinking "20" is a good limit) Section 8: s/RECOMMENDED to not impose a hard limit/NOT RECOMMENDED to impose a hard limit/ |
2016-05-03
|
06 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2016-05-03
|
06 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2016-05-03
|
06 | Kathleen Moriarty | [Ballot comment] I think the Complexity mentioned in section 4 should be a security consideration since there are more opportunities for mistakes that lead to … [Ballot comment] I think the Complexity mentioned in section 4 should be a security consideration since there are more opportunities for mistakes that lead to data leakage. |
2016-05-03
|
06 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2016-05-03
|
06 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2016-05-03
|
06 | Alissa Cooper | [Ballot comment] Section 3: s/which is only available in 3GPP release 10/which has been made available as of 3GPP release 10/ Section 9.1: - May … [Ballot comment] Section 3: s/which is only available in 3GPP release 10/which has been made available as of 3GPP release 10/ Section 9.1: - May be better not to presume that operators do things "to avoid liability" - I don't think that particular sentence is necessary here. - I was surprised not to see a note here about interaction between this kind of host tracking and MAC address randomization, which I assume makes tracking harder independently of the whether the recommendations in this document are followed. But is it not discussed because operators who feel they need these kind of logs also prohibit MAC randomization? |
2016-05-03
|
06 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2016-05-03
|
06 | Mirja Kühlewind | [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind |
2016-05-03
|
06 | Alexey Melnikov | [Ballot comment] This is a well written document which argues well for assigning multiple IPv6 addresses per host. |
2016-05-03
|
06 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2016-04-27
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2016-04-27
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2016-04-10
|
06 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Victor Kuarsingh |
2016-04-10
|
06 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Victor Kuarsingh |
2016-04-07
|
06 | Jonathan Hardwick | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Geoff Huston. |
2016-04-07
|
06 | Roni Even | Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. |
2016-04-01
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2016-04-01
|
06 | Joel Jaeggli | Placed on agenda for telechat - 2016-05-05 |
2016-04-01
|
06 | Joel Jaeggli | IESG state changed to IESG Evaluation from Waiting for Writeup |
2016-04-01
|
06 | Joel Jaeggli | Ballot has been issued |
2016-04-01
|
06 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2016-04-01
|
06 | Joel Jaeggli | Created "Approve" ballot |
2016-04-01
|
06 | Joel Jaeggli | Ballot writeup was changed |
2016-04-01
|
06 | Joel Jaeggli | Changed consensus to Yes from Unknown |
2016-03-09
|
06 | Lorenzo Colitti | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2016-03-09
|
06 | Lorenzo Colitti | New version available: draft-ietf-v6ops-host-addr-availability-06.txt |
2016-03-09
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2016-03-08
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Victor Kuarsingh. |
2016-03-02
|
05 | Jonathan Hardwick | Request for Last Call review by RTGDIR is assigned to Geoff Huston |
2016-03-02
|
05 | Jonathan Hardwick | Request for Last Call review by RTGDIR is assigned to Geoff Huston |
2016-02-29
|
05 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2016-02-29
|
05 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-v6ops-host-addr-availability-05.txt, which is currently in Last Call, and has the following comments: We understand that this … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-v6ops-host-addr-availability-05.txt, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal IANA Specialist ICANN |
2016-02-27
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2016-02-27
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2016-02-25
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2016-02-25
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2016-02-25
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2016-02-25
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2016-02-24
|
05 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2016-02-24
|
05 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: v6ops@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability@ietf.org, joelja@gmail.com, v6ops-chairs@ietf.org, draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: v6ops@ietf.org, fred.baker@cisco.com, draft-ietf-v6ops-host-addr-availability@ietf.org, joelja@gmail.com, v6ops-chairs@ietf.org, draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Host address availability recommendations) to Best Current Practice The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Host address availability recommendations' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and describes the benefits of and the options for doing so. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ballot/ No IPR declarations have been submitted directly on this I-D. |
2016-02-24
|
05 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2016-02-24
|
05 | Joel Jaeggli | Last call was requested |
2016-02-24
|
05 | Joel Jaeggli | Last call announcement was generated |
2016-02-24
|
05 | Joel Jaeggli | Ballot approval text was generated |
2016-02-24
|
05 | Joel Jaeggli | Ballot writeup was generated |
2016-02-24
|
05 | Joel Jaeggli | IESG state changed to Last Call Requested from AD Evaluation |
2016-02-15
|
05 | Joel Jaeggli | IESG state changed to AD Evaluation from Publication Requested |
2016-02-15
|
05 | Fred Baker | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The title page, and working group discussion, requests BCP status. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and describes the benefits of and the options for doing so. Working Group Summary This particular draft has not been controversial; it borders on stating the obvious, and certainly states a consensus of IPv6 operators and designers in the IETF. It does, however, recommend a change from current general practice with DHCP/DHCPv6, a change that the author's companies are explicitly exploring and finding useful, which is to allocate a prefix to a host rather than a single address. Document Quality This is not a protocol, it is a proposal regarding IPv6 protocol deployment practice. That said, yes, there are multiple implementations. Windows, MacOSX, Linux, and other operating systems expect to use multiple addresses in the same prefix simultaneously, and common practice using SLAAC directly supports this. The issue has to do with DHCP/DHCPv6 address allocation, which a network operator might restrict to a single address unnecessarily. Personnel The Document Shepherd is Fred Baker. The AD is Joel Jaegli. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. When the initial draft was posted (July 2015), I read it and suggested to the working group that this might express an existing consensus and be worth simply sending in. There was discussion, which I followed. I have read versions 4 and 5 of the draft, and agree with its comments. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I don't think it needs review, per se, but it would be worth ensuring that the DHCP Working Group is aware of it, as the topic may affect their thinking. The draft mentions DHCP-PD deployment to a host, as opposed to to a network, which is being experimented with in multiple scenarios and discussed in the IETF. NVO3 may also be interested. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I am comfortable with the document and its recommendations. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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? I would describe the consensus behind this document as "very solid". (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. In section 9.2, the draft comments on the use of RFC 1918 addresses in IPv4 networks, and specifically mentions two of those prefixes. The mention is accurate. The "security considerations" section could be described as "minimal". That said, the statement is accurate: no security considerations have been identified. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. It doesn't need that. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no requests made to IANA, and that is stated to be the case. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None. |
2016-02-15
|
05 | Fred Baker | Responsible AD changed to Joel Jaeggli |
2016-02-15
|
05 | Fred Baker | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2016-02-15
|
05 | Fred Baker | IESG state changed to Publication Requested |
2016-02-15
|
05 | Fred Baker | IESG process started in state Publication Requested |
2016-02-15
|
05 | Fred Baker | Changed document writeup |
2016-02-12
|
05 | Lorenzo Colitti | New version available: draft-ietf-v6ops-host-addr-availability-05.txt |
2016-01-03
|
04 | Lorenzo Colitti | New version available: draft-ietf-v6ops-host-addr-availability-04.txt |
2015-12-10
|
03 | Fred Baker | Changed document writeup |
2015-12-10
|
03 | Fred Baker | Notification list changed to draft-ietf-v6ops-host-addr-availability.all@tools.ietf.org from "Fred Baker" <fred.baker@cisco.com> |
2015-12-10
|
03 | Fred Baker | Intended Status changed to Best Current Practice from None |
2015-12-10
|
03 | Fred Baker | Notification list changed to "Fred Baker" <fred.baker@cisco.com> |
2015-12-10
|
03 | Fred Baker | Document shepherd changed to Fred Baker |
2015-12-10
|
03 | Lorenzo Colitti | New version available: draft-ietf-v6ops-host-addr-availability-03.txt |
2015-11-01
|
02 | Lorenzo Colitti | New version available: draft-ietf-v6ops-host-addr-availability-02.txt |
2015-09-03
|
01 | David Schinazi | New version available: draft-ietf-v6ops-host-addr-availability-01.txt |
2015-07-31
|
00 | Fred Baker | This document now replaces draft-colitti-v6ops-host-addr-availability instead of None |
2015-07-31
|
00 | David Schinazi | New version available: draft-ietf-v6ops-host-addr-availability-00.txt |