Issues with Private IP Addressing in the Internet
draft-ietf-grow-private-ip-sp-cores-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-10
|
07 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-08-08
|
07 | (System) | IANA Action state changed to No IC |
2012-08-08
|
07 | Cindy Morgan | State changed to Approved-announcement to be sent from None |
2012-08-08
|
07 | Cindy Morgan | IESG has approved the document |
2012-08-08
|
07 | Cindy Morgan | Closed "Approve" ballot |
2012-08-08
|
07 | Cindy Morgan | Ballot approval text was generated |
2012-08-08
|
07 | Cindy Morgan | Ballot writeup was changed |
2012-07-31
|
07 | Ron Bonica | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-07-31
|
07 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
2012-07-30
|
07 | Anthony Kirkham | New version available: draft-ietf-grow-private-ip-sp-cores-07.txt |
2012-07-30
|
06 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2012-07-30
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-07-30
|
06 | Cindy Morgan | New version available: draft-ietf-grow-private-ip-sp-cores-06.txt |
2012-07-19
|
05 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead |
2012-07-19
|
05 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-07-19
|
05 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-07-18
|
05 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-07-18
|
05 | Barry Leiba | [Ballot discuss] This is a very straightforward, simple DISCUSS for an IANA issue. In Section 5, the following text makes it look like a request … [Ballot discuss] This is a very straightforward, simple DISCUSS for an IANA issue. In Section 5, the following text makes it look like a request is being made of IANA: To address this scenario and others, "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] requests a dedicated /10 address block for the purpose of Shared CGN (Carrier Grade NAT) Address Space. IANA suggests that it be changed to this, and I agree that it needs to change to make it clear that this allocation already exists, and is not a new request: To address this scenario and others, "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] allocated a dedicated /10 address block for the purpose of Shared CGN (Carrier Grade NAT) Address Space: 100.64.0.0/10. |
2012-07-18
|
05 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2012-07-18
|
05 | Adrian Farrel | [Ballot comment] I have no objection to the publication of this document. It did feel to me,on reading the doument, that the problems reported are … [Ballot comment] I have no objection to the publication of this document. It did feel to me,on reading the doument, that the problems reported are all associated with attempting to deploy a flat network using private addressing. However, the observation that one motivting factor is "core hiding" makes it reasonable to observe that the problems do not exist if proper network layereing is applied. Of course, such layering makes network operation more complex and also makes some functions (like traceroute) impossible or secret, while other functions (such as PMTUD) require cross-layer coordination. That doesn't detract from the document, but suggest that issues may be less black/white. OTOH one might note that IPv6 removes the largest "need" for private addressing and so this document should be reporting an interesting quirk of history! |
2012-07-18
|
05 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-07-18
|
05 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-07-18
|
05 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-07-18
|
05 | Russ Housley | [Ballot comment] Please consider the suggested changes from the Gen-ART Review by Suresh Krishnan on 16-July-2012. The review can be found here: … [Ballot comment] Please consider the suggested changes from the Gen-ART Review by Suresh Krishnan on 16-July-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07609.html |
2012-07-18
|
05 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-07-18
|
05 | Martin Stiemerling | [Ballot comment] I support Brian's DISCUSS point no. 1 about why only TCP is named for PMTUD in Section 4. Another point to be considered: … [Ballot comment] I support Brian's DISCUSS point no. 1 about why only TCP is named for PMTUD in Section 4. Another point to be considered: Section 5., paragraph 1: > Private addressing is legitimately used within many enterprise, > corporate or government networks for internal network addressing. > When users on the inside of the network require Internet access, they > will typically connect through a perimeter router, firewall, or > network proxy, that provides Network Address Translation (NAT) or > Network Address Port Translation (NAPT) services to a public > interface. Why not simply saying that this type of traffic passes through a NAT when heading for the public Internet. It does not matter if the NAT is implemented on a stand-alone device, a router, a set top box, etc. The current text might just cause confusion for an average reader. |
2012-07-18
|
05 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-07-17
|
05 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-07-17
|
05 | Suresh Krishnan | Request for Last Call review by GENART Completed. Reviewer: Suresh Krishnan. |
2012-07-17
|
05 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-07-16
|
05 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-07-16
|
05 | Brian Haberman | [Ballot discuss] These issues should be relatively easy to address, but please feel free to discuss them with me if you have a different point … [Ballot discuss] These issues should be relatively easy to address, but please feel free to discuss them with me if you have a different point of view. 1. I don't understand why Section 4 is limiting Path MTU Discovery to TCP use cases. The referenced RFCs are applicable to other transport protocols as well. I would suggest dropping any references to TCP in that section and have it focus on the general issues that PMTUD could/would encounter in the scenarios described. 2. Section 5 makes the statement: "Scarcity of public IPv4 addresses, and the transition to IPv6, is forcing many service providers to make use of NAT." I don't believe that the transition to IPv6 is forcing ISPs to deploy NATs. I would suggest deleting that clause. 3. I was surprised to read in Section 7 that it is *uncommon* for peering relationships to be anchored on loopback addresses. I have been told several times that this technique is quite common and allows for peering sessions to survive link/interface outages. Is there a pointer/reference that can be added that supports this assertion? |
2012-07-16
|
05 | Brian Haberman | [Ballot comment] 1. The document uses several acronyms without expansion. For example, the introduction does not expand RIR on its first use. 2. The note … [Ballot comment] 1. The document uses several acronyms without expansion. For example, the introduction does not expand RIR on its first use. 2. The note in the introduction could be clarified. I don't think "stolen" is appropriate in this context. The draft actually uses the correct term "squat", but only as an alternative. I would suggest removing the use of "stolen" and replacing it with "squat" since addresses are not property. 3. The figures, especially the one in Section 3, are hard to follow. Would it be possible to re-work them with more/better delineation between devices? I can provide an example if it would help. |
2012-07-16
|
05 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2012-07-13
|
05 | Benoît Claise | [Ballot comment] When I read in the abstract RFC1918 + loopbacks, I was immediately thinking: that's bad from a opeational/management point of view, because, in … [Ballot comment] When I read in the abstract RFC1918 + loopbacks, I was immediately thinking: that's bad from a opeational/management point of view, because, in many networks, the loopback IP address is the unique router identifier in the NMS applications. Thinking some more... as long as the loopback addresses are unique, this should be fine. However, applying RFC1918 IP addresses to loopbacks is still looking for problem from an operational point of view. - Let's assume, in this world of acquisitions, that the network operator has to merge two networks, each using the same same private IP block for their respective loopbacks... he has to renumber one of the two networks. - Let's assume, in this connected world, that the network operator has to compare NetFlow/IPFIX flow records from different routers in different networks and those networks use the same private IP addresses block for their respective loopbacks... He has a problem, because, most of the time, the unique id in the collector is the source IP address of the UDP export, so the loopback. Same thing for syslog btw. I'm wondering if it would not be worth completing the section 9 "Operational and Troubleshooting issues"? |
2012-07-13
|
05 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-07-13
|
05 | Ron Bonica | Placed on agenda for telechat - 2012-07-19 |
2012-07-11
|
05 | Pearl Liang | IANA has reviewed draft-ietf-grow-private-ip-sp-cores-05, which is currently in Last Call, and has the following comments: IANA notes that this document does not contain a … IANA has reviewed draft-ietf-grow-private-ip-sp-cores-05, which is currently in Last Call, and has the following comments: IANA notes that this document does not contain a standard IANA Considerations section. After examining the draft, IANA understands that, upon approval of this document, there are no IANA Actions that need completion. However, IANA recommends that the text in section 5 which says: "To address this scenario and others, "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] requests a dedicated /10 address block for the purpose of Shared CGN (Carrier Grade NAT) Address Space." be changed as follows for clarity and to indicate that an allocation has been made: "To address this scenario and others, "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] allocated a dedicated /10 address block for the purpose of Shared CGN (Carrier Grade NAT) Address Space: 100.64.0.0/10." |
2012-07-11
|
05 | Ron Bonica | Ballot has been issued |
2012-07-11
|
05 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica |
2012-07-11
|
05 | Ron Bonica | Created "Approve" ballot |
2012-07-05
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2012-07-05
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2012-07-05
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-07-05
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-07-03
|
05 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Issues with Private IP Addressing in … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Issues with Private IP Addressing in the Internet) to Informational RFC The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Issues with Private IP Addressing in the Internet' as Informational RFC 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 2012-07-17. 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 The purpose of this document is to provide a discussion of the potential problems of using private, RFC1918, or non-globally- routable addressing within the core of an SP network. The discussion focuses on link addresses and to a small extent loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-grow-private-ip-sp-cores/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-grow-private-ip-sp-cores/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-07-03
|
05 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2012-07-03
|
05 | Ron Bonica | Last call was requested |
2012-07-03
|
05 | Ron Bonica | Last call announcement was generated |
2012-07-03
|
05 | Ron Bonica | Ballot approval text was generated |
2012-07-03
|
05 | Ron Bonica | State changed to Last Call Requested from AD Evaluation |
2012-07-03
|
05 | Ron Bonica | State changed to AD Evaluation from Publication Requested |
2012-07-03
|
05 | Ron Bonica | Ballot writeup was changed |
2012-07-03
|
05 | Ron Bonica | Ballot writeup was changed |
2012-07-03
|
05 | Ron Bonica | Ballot writeup was generated |
2012-07-03
|
05 | Amy Vezza | (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? This is in the Informational Track, this is appropriate for the subject matter and guidelines outlined in the document itself. (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 The purpose of this document is to provide a discussion of the potential problems of using private, RFC1918, or non-globally- routable addressing within the core of an SP network. The discussion focuses on link addresses and to a small extent loopback addresses. While many of the issues are well recognized within the ISP community, there appears to be no document that collectively describes the issues. Working Group Summary This document had extensive review through the wg process. I believe there was good discussion about merits, improvements and polishing for this document, I believe the WG consensus long ago that this document is ready for publication. Document Quality This document aims to outline the pitfalls with certain implementation choices in building/operating a network which is to be part of the larger public Internet. It is a good, solid document. Personnel The document shepherd is myself (Chris Morrow), the responsible Area Directors are: Ron Bonica Benoit Claise (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. As the document shepherd I've reviewed several versions of this document, I believe it is ready (as does the author, editor and wg) for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document shepherd has no concerns with the reviews which have been performed to date. (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. The document shepherd does not believe further speciality review is required at this time. (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. Aside from the tardiness of this pub-request I don't think there are any other concerns. (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. The document shepherd believes that all IPR concerns are laid to rest. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures in flight for this document. (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? The WG consensus is very strong that this document should move forward. (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.) There are no threatened appeals or other issues. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are a few nits from the online idnits tool, the only one of merit is: "== Unused Reference: 'RFC792' is defined on line 598, but no explicit reference was found in the text" The author can fix this issue further down the process pipeline, during IESG comment debates. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There is no review required for formal criteria/ (13) Have all references within this document been identified as either normative or informative? The document shepherd believes that all references are dealt with properly. (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? There is a single reference (to RFC792) which the author can adjust when the time comes. (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. There are no downward normative references. (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 existing RFCs will be changed with the publication of this draft. (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 is no IANA Considerations document, I don't believe there needs to be one for this document. (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. idnits was run, along with spellcheck. |
2012-07-03
|
05 | Amy Vezza | Note added 'The document shepherd is Chris Morrow (christopher.morrow@gmail.com).' |
2012-07-03
|
05 | Amy Vezza | Intended Status changed to Informational |
2012-07-03
|
05 | Amy Vezza | IESG process started in state Publication Requested |
2012-06-16
|
05 | Anthony Kirkham | New version available: draft-ietf-grow-private-ip-sp-cores-05.txt |
2012-05-12
|
04 | Anthony Kirkham | New version available: draft-ietf-grow-private-ip-sp-cores-04.txt |
2012-05-07
|
03 | Anthony Kirkham | New version available: draft-ietf-grow-private-ip-sp-cores-03.txt |
2012-04-24
|
02 | Anthony Kirkham | New version available: draft-ietf-grow-private-ip-sp-cores-02.txt |
2012-04-09
|
01 | Anthony Kirkham | New version available: draft-ietf-grow-private-ip-sp-cores-01.txt |
2012-03-28
|
00 | Anthony Kirkham | New version available: draft-ietf-grow-private-ip-sp-cores-00.txt |