Issues Associated with Designating Additional Private IPv4 Address Space
draft-azinger-additional-private-ipv4-space-issues-05

[Ballot comment]
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 10.0.0.0/8 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
space.

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
conclusions.

[Ballot comment]
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:

OLD
  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
  clashes.
NEW
  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.
END

[Ballot discuss]
My Discuss updated for -05

I support this document as a really helpful anchor for discussing an
important problem space.

I was surprised not to find any mention of unnumbered interfaces. Your revised text says "..need to number..." and I understand that the document addresses the shortage of numbers, but the "need to number" is (perhaps) a mystery to the reader: why is there a need to number the interfaces.

[Ballot discuss]
This position is mostly a discuss-discuss; I'd like to discuss some of the basic premises from which the doc is written.

I don't see any acknowledgments of review by or input from other stakeholders like service providers, wireless operators, etc.  I've asked John Brzozowski (Comcast) for his comments, which he expects to send to me by Sep 3.

In my opinion, the document is not clear on the distinction between RFC 1918 addresses used to number "internal" interfaces, which are only used for internal communication, and addresses used to number "subscriber" interfaces, which need global access.  So, for example, in section 3:

  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
  be acknowledged that NAT is adequate in some situations and not in
  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.

unless the operator is using RFC 1918 address space for subscriber devices (e.g., HGW, host, mobile device), I don't see how this text is relevant to RFC 1918 address space exhaustion.

A little farther along in section 3:

  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].

This text, if I understand it correctly, talks about sharing a global address (not RFC 1918 space) among multiple subscribers, and isn't germane to the discussion of RFC 1918 address space exhaustion.

Regarding section 4.2: if the addresses in question are truly site-scoped and not routed outside the operator's domain, how is the (probabilistically unlikely) prefix clash a problem?  Is the use of IPv6 ULAs any more difficult than the use of IPv6 GUAs; I don't undertstand the different descriptions for the problems listed in sections 4.1 and 4.2.

In section 4.3, are the global addresses in question for use in supplementing internal addressing for which RFC 1918 is insufficient?  Is it feasible to obtain enough addresses in this way to make significantly more address space available than is in 10/8?

In section 5.3:

  If additional private address space is not defined and the large
  network operators affected by this problem are not able to solve
  their problems with IPv6 address space or by segmenting their
  networks into multiple routing domains, those networks will need
  unique IPv4 addresses.  It is possible and even likely that a single
  network could consume a whole IPv4 /8 in a year.

Is this projected rate of consumption based on global addresses required for subscriber equipment accessing the Internet and (potentially) private addresses for numbering internal interfaces?  Do the authors have any data to support their claim?

[Ballot discuss]
This position is mostly a discuss-discuss; I'd like to discuss some of the basic premises from which the doc is written.

I don't see any acknowledgments of review by or input from other stakeholders like service providers, wireless operators, etc.  I've asked John Brzozowski (Comcast) for his comments, which he expects to send to me by Sep 3.

In my opinion, the document is not clear on the distinction between RFC 1918 addresses used to number "internal" interfaces, which are only used for internal communication, and addresses used to number "subscriber" interfaces, which need global access.

[Ballot comment]
Thomas Narten's review:

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

Thomas


> >    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

better:

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


> >    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
document.

> >    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
believe.

> >    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
later.)

> >    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
clear.

> > 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

s/be///

> >    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...

[Ballot discuss]
This is a very much needed document. The document is on the right track,
but falls short on a couple of aspects. I would like to recommend
revising the document once before we approve it.

My main concern is that in my recollection the IETF made a very clear
decision. All the discussion pointed to saying "no" for any new
address space allocation for private addressing. There were numerous
arguments why this is the right course of action. However, the document
falls short of actually stating this. The document needs to say clearly
that the IETF recommends against new private address space allocations.

A couple of other issues:

  It is not always
  possible to rely on CPE devices using any particular range, however.
  In some cases this means that CPE devices can use unallocated address
  space or address space allocated to other network operators.

I have heard of operators running on unallocated address space, but
never of CPEs. CPEs may default to different values with the RFC 1918
range of course. (Though when we talked about this in OPSAREA a couple
of IETFs ago Dave Tahler pointed out that majority if not all new
equipment defaults to 192.168/16.) But CPE that defaults to unallocated
or someone's address space? Really? Do we have evidence of this from the
field?

In any case, the document does not describe what is the key problem
for the CPE: having a *different* address range than the service provider
network has.

  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.

It would be good to mention already here that some ways of allocating
new address space on the IPv4 side would result in equivalent
implementation/deployment issues (such as updating all routers and
hosts across the Internet to not drop 240/4).

I would also like to see Thomas Narten's comment on peer-to-peer
addressed (see below for a copy of his review).

Finally, I think the section that talks about address sharing
across multiple subscribes is probably a little too simplified.
Note that the IETF already has ongoing work about such mechanisms
(e.g., dual stack lite which implements a CGN to share addresses).
I think the true driver behind new private address space is that
the service providers do not want "new" solutions (such as IPv6,
dual stack lite) but rather want to keep existing customer NATs
and add one of their own.

[Ballot comment]
Thomas Narten's review:

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

Thomas


> >    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

better:

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


> >    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
document.

> >    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
believe.

> >    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
later.)

> >    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
clear.

> > 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

s/be///

> >    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...

[Ballot discuss]
I support this document as a really helpful anchor for discussing an
important problem space.

My Discuss is around the scope of the problem as expressed in the
document.

1. I got snarled up with some of the language around "interfaces". My
  initial reaction was to assume that you were talking about interfaces
  as links between routers. These are indentified for use in routing
  protocols, but do not need to be routable entities. Thus, I was
  surprised not to find any mention of unnumbered interfaces.
  But I suspect you are intending to scope to "interfaces to the
  network" since the text seems to focus on addressable points of
  attachment.
  Could we discuss this and, if I am right in my suspiscions, perhaps
  you could look at how to clrify this in the text.

2. 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.

[Ballot comment]
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'