Issues Associated with Designating Additional Private IPv4 Address Space
RFC 6319

Note: This ballot was opened for revision 05 and is now closed.

Lars Eggert No Objection

Comment (2010-08-23 for -)
No email
send info
INTRODUCTION, paragraph 2:
>                   Additional Private IPv4 Space Issues

  Nit: Title can be misunderstood (as in "this doc talks about
  additional issues with regards to private address space.") Maybe:
  "Issues with Assigning Additional IPv4 Private Address Space"?

Section 3., paragraph 0:
> 3.  Network Address Translation

  I wish this section were more clear about the significant downsides
  that multiple levels of NAT have compared to a single level of NAT.

Section 8.1., paragraph 2:
>    [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
>               Understanding Concerning the Technical Work of the
>               Internet Assigned Numbers Authority", RFC 2860, June 2000.

  Nit: Unused Reference: 'RFC2860'

(Ron Bonica; former steering group member) Yes

Yes ( for -)
No email
send info

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2011-01-16)
No email
send info
This point moved from the previous Discuss and updated.

I found the example of VPNs a little uncomfortable (section 2). I believe that the VPN technologies developed in the IETF have included good precautions to avoid "address clashes" and, while I can believe that folk feel uneasy knowing that customer spaces have overlapping address spaces, this is not actually a significant risk.

I have re-read the text and I can probably live with the current text, although I would not mind to see:

   In the case of private internets
   and VPN service providers there are multiple independently managed
   and operated networks and the difficulty is in avoiding address
   In the case of private internets
   and VPN service providers there are multiple independently managed
   and operated networks and it is important to avoid address clashes.

(David Harrington; former steering group member) No Objection

No Objection (2010-08-23 for -)
No email
send info
s/It is be/It is/

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection (2010-08-25)
No email
send info
Thomas Narten's review:

Overall, I think the document is useful, but another pass would be
good. My review comments below.


> >    any Internet registry.  Very large networks can find that they need
> >    to connect more interfaces than the number of addresses available in
> >    these three ranges.  It has occasionally been suggested that


    Very large networks can find that they need to number more device
    interfaces than there are available addresses in these three

> >    these three ranges.  It has occasionally been suggested that
> >    additional private IPv4 address space should be reserved for use by
> >    these networks.  Although such an action might address some of the
> >    needs for these very large network operators it is not without
> >    consequences, particularly as we near the date when the IANA free
> >    pool will be fully allocated.

This document should (probably) say that the question of reserving
more private space is out of scope and not adddressed by this

> >    The address space set aside in [RFC1918] is a finite resource which
> >    can be used to provide limited Internet access via Network Address
> >    Translation (NAT).  A discussion of the advantages and disadvantages
> >    of NATs is outside the scope of this document.  Nonetheless, it must

But at least provide references  to some of the documents that do
discuss that... I think the IAB has authored 2..

> >    others.  For instance, it is often technically feasible to use NAT or
> >    even multiple layers of NAT within the networks operated by
> >    residential users or corporations where peer to peer communication is
> >    not needed.  Where true peer to peer communication is needed or where

This is too simplistic. Its not just peer-to-peer. More like if only
clients (and no servers) are behind the NAT. This document is likely
to have problems trying to summarize the pros/cons of NAT. Can't you
just point to some other document and move on?

I particularly object to the word "often" above. It all depends on
what you are doing, and "often" suggests it mostly works.

> >    In many cases it is possible to use multiple layers of NAT to re-use
> >    parts of the address space defined in [RFC1918].  It is not always

Again, "in many cases" sets the wrong tone, IMO.

> >    In some cases this means that CPE devices can use unallocated address
> >    space or address space allocated to other network operators.  In

"can use" is a very positive tone and suggests this is a good idea or
acceptable. Please rephrase.

> >    Another option is to share one address across multiple interfaces and
> >    in some cases, subscribers.  This model breaks the classical model
> >    used for logging address assignments and creates some risks
> >    [CLAYTON].  This concept is more fully explored in [FORD].

how can using the same address by multiple susbcribers work? How do
you make routing work?

> > 4.1.  Unique Globally Scoped IPv6 Unicast Addresses
> > 
> >    Using unique, globally scoped IPv6 unicast addresses is the preferred
> >    option as it removes any concerns about address scarcity.  In some
> >    cases implementing a new network protocol on a very large network
> >    takes more time than is available, based on network growth and the
> >    proportion of private space that has already been used.  In these
> >    cases, there is a call for additional private address space that can
> >    be shared by all network operators.  [DAVIES] makes one such case.
> >

This section needs work. Deploying IPv6 is not a simple solution for
someone running out of IPv4 space. What about providing backwards
compatability with IPv4?

What might be best is to just say that moving to IPv6 is the best long
term solution, but in the short term having IPv4 is probably still a
requirement. And that this document just focusses on IPv4.

Making it sound like you can just move to IPv6 as a solution is silly
and not helpful.

Also, I'd put 4.1 and 4.2 into their own section that focusses on IPv6
issues. These are the only 2 subsections that talk about IPv6, I

> >    cost.  However, it is unlikely to become available in large
> >    contiguous blocks and this would add to the network managment burden
> >    for the operator.

You might want to explain what the increased burden is. ALso, you
don't say how much of a burdon this would be. Presumably, running out
of usable space is a bigger burden to have to deal with...

> >  For these reasons, address transfers will not be
> >    an attractive proposition to many large network operators.

This is just the author's opinion. Better to say something more like:

  For these reasons, address transfers will likely provide only
  limited help to many large network operators.

And, BTW, what is "large"?  

> > Leases
> >    might not be attractive to some organizations if both parties cannot
> >    agree a suitable length of time.  Also, the lessor might worry about
> >    its own unanticipated needs for additional IPv4 address space.

I think the above can be dropped. There are many issues that would
impact the viability of such an approach. You only mention a couple,
and I'm not sure they are even the important ones.

> > 4.4.  Using Unannounced Address Space Allocated to Another Organization
> > 
> >    Some network operators have considered using IP address space which
> >    is allocated to another organization but is not publicly visible in
> >    BGP routing tables.  This option is very strongly discouraged as the
> >    fact that an address block is not visible from one view does not mean

Just "strongly discouraged?" Shame on you! This should not be
recommended at all, as it can lead to interoperability problems to
sites that legitimately own that space. (You start to mention them

> >    queries, traceroute output and other ways.  The ambiguity this causes
> >    is problematic for multiple organizations.  This issue is addressed
> >    in [RFC3879], section 2.3.

"is addressed" is wrong wording. I think you mean to say that this
issue is discussed in more detail on that section....

> >    It is also possible that the registrant of the address block might
> >    want to increase its visibility to other networks in the future,
> >    causing problems for anyone using it unofficially.  In some cases
> >    there might also be legal risks involved in using address space
> >    officially allocated to another organization.

It's not just if it is announced publically, also happens if the
network interconnect privately...

> > 4.5.  Unique IPv4 Space Registered by an RIR
> > 
> >    The policy framework shared by the RIRs does not discriminate based
> >    on what an address is used to do, just on how efficiently the
> >    assigned addresses are used.

Please just say: RIR policies allow organizations to get public space
even if the addresses will only be used for internal purposes.

> > Unique IPv4 addresses registered by an
> >    RIR are potentially available to organizations whose networks have
> >    used all the addresses set aside in [RFC1918].

This makes it sound like you have to first use up your addresses
before going to an RIR. That is not true and should be made more

> > Nonetheless, network
> >    operators are naturally disinclined to request unique IPv4 addresses
> >    for a purpose that could be met with private addresses were it not
> >    for the size of the network because addresses assigned in this way
> >    are not available for anyone else to use and so their registration
> >    denies them to new entrants, including potential customers.

I don't quite understand what this is trying to say...

> >    It is be possible to re-designate a portion of the current global


> >    When considering re-designating a portion of the current global
> >    unicast IPv4 address space as private unicast address space it is
> >    important to consider how much space would be used and for how long
> >    it would be sufficient.  Not all of the large networks making full
> >    use of the space defined in [RFC1918] would have their needs met with
> >    a single /8.  In 2005, [HAIN] suggested reserving three /8s for this
> >    purpose while in 2009 [DAVIES] suggested a single /10 would be
> >    sufficient.  There does not seem to be a consensus for a particular
> >    prefix length nor an agreed basis for deciding what is sufficient.
> >    The problem is exacerbated by the continually changing needs of ever
> >    expanding networks.

Actually, there has not been consensus to reserver *any* additional
space. The above should say that clearly. Saying we just haven't
agreed on the size is misleading.

Hmm. this document just ends without a summery or recommendation. That
doesn't seem right...

(Ralph Droms; former steering group member) (was Discuss) No Objection

No Objection (2011-04-25)
No email
send info
I've cleared my DISCUSS.  I would like to see these remaining COMMENTs
addressed before the document is published. 

In section 2, why are cable operators explicitly called out; why not
more generally "service providers"? 
The purpose of section 3 is still unclear to me.  I don't think there
is any question about the need to use RFC 1918 address space.  My
understanding is that this document is intended to provide information
about scenarios in which RFC 1918 address space is inadequate, and
possible mitigations for that problem.  The scenarios in section 3
seem to me to describe how to use RFC 1918 address space to extend the
availability of global IPv4 address space.  There is a mention of
multiple layers of NAT used to re-use RFC 1918 address space, but
only, as far as I can tell, in support of extending IPv4 global
address space.

In section 5.1, if the defined in RFC 1918 is insufficient,
how would the additional reservation of a /10 be of any help?  You
might want to include in the doc any advantages to new reservation of
IPv4 address space that is guaranteed not to conflict with RFC 1918

Subections 5.3 and 5.4 seem out of order.  Better yet, subsection 5.3
might be better organized as a separate section on consequences and

(Robert Sparks; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (2010-08-26 for -)
No email
send info
  Some of the references are Internet-Drafts.  These need to be marked
  as work-in-progress.

(Sean Turner; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -)
No email
send info