Skip to main content

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