Issues with IP Address Sharing
draft-ietf-intarea-shared-addressing-issues-05

Received changes through RFC Editor sync (changed abstract to 'The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope.

Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. This document is not an Internet Standards Track specification; it is published for informational purposes.')

[Ballot comment]
Please consider the comments from the Gen-ART Review by
  Francis Dupont on 16-Feb-2011:

  - 5.2.1 page 11: I have a concern about the word 'relay' in
    'a UPnP or NAT-PMP relay' as it can be interpreted as a protocol
    relay when obviously the service is relayed. Perhaps changing
    'relay' by 'proxy' is better?

  - 6 page 13: ICMP is not an application, I suggest 'ICMP echo' or
    (for me it is the name of the application but I don't know for any
    OS users) 'ping'

  - 7 page 14, 13.2 page 18: e.g. -> e.g.,

  - 13.5 page 19: please take the opportunity to introduce the 'IKE'
    abbrev

  - 26.[12] page 24: spurious spaces after citations.
    i.e., '[ref...] ,' -> '[ref...].'
    (IMHO it is a side effect of the xml style, so something to be fixed
    by the RFC Editor, i.e., just warn him about this)

  - in many places the English spelling is used when RFCs use more
    the American spelling (another item for the RFC Editor).
    Here is the list from my ispell:
      Randomisation, Behaviour, organisation, randomisation, realise,
      customised, centralised, randomisation, Randomisation,
      randomisation, randomisation, Behaviour, optimisation,
      optimisation, utilise, utilise

  - real spelling errors:
      Feburary, tunnelled (one 'l' please), demuxing,
      signalling (twice, one 'l' again)

[Ballot comment]
If the
  percentage of end-to-end IPv6 traffic significantly increases, so
  that the volume of IPv4 traffic begins decreasing, then the number of
  IPv4 sessions will decrease.

This sentence seems to imply a predicted correlation. It does not follow that the increase in IPv6 traffic will reduce the volume of IPv6 traffic.

[Ballot comment]
13.6.  Policing Forwarding Behaviour

  If some form of IPv6 ingress filtering is deployed in the broadband
  network and DS-Lite service is restricted to those subscribers, then
  tunnels terminating at the CGN and coming from registered subscriber
  IPv6 addresses cannot be spoofed.  Thus a simple access control list
  on the tunnel transport source address is all that is required to
  accept traffic on the southbound interface of a CGN.

Is "southbound" a common terminology?


17.  IPv6 Transition Issues

  Subscribers allocated with private addresses will not be able to
  utilise 6to4 to access IPv6, but may be able to utilise Teredo.

This needs an Informative reference.


The first reference to HTTP needs an Informative reference.

[Ballot comment]
In Figure 1, while reverse DNS is affected (more precisely, broken) by
NAT without address sharing, in my opinion it is affected differently
(more broken) by address sharing.  Might deserve "xx"?

[Ballot discuss]
I don't understand this sentence:

17.  IPv6 Transition Issues

  [...]

  Shared addresses should be drawn from space designated as such
  [RFC1918].  Otherwise their use will break the widely implemented
  assumption that public IPv4 addresses are globally unique addresses
  and hence break many protocols and applications, [...]

Which "shared addresses" are under discussion here?  Isn't the
motivation for this document the need to share public addresses
because of IPv4 address exhaustion?

Later in the same section:

  Issues created by sharing public address
  space across multiple hosts are specifically addressed in
  [I-D.thaler-port-restricted-ip-issues].

Isn't thaler-port-restricted-ip-issues just focused on issues with A+P
addressing, not generally public address space sharing issues?

Does address sharing affect any other transition technologies, or just
6-to-4?

[Ballot discuss]
I'm adding a placeholder discuss to make sure the discussion between the authors and the tsv-dir reviewer terminates and we have a version submitted that addresses all comments.

[Ballot discuss]
This document calls out to draft-thaler-port-restricted-ip-issues for several important discussions, but that document has not been refreshed since Feb-10, and I'm not finding any other signs of activity around it. What is the plan for moving that document forward?

[Ballot comment]
Section 1., paragraph 1:
>    Authority (IANA) were completed on Feburary 3, 2011 [IPv4_Pool].

  Nit: s/Feburary/February/


Section 1., paragraph 3:
>    Over the long term, deploying IPv6 is the only way to ease pressure
>    on the public IPv4 address pool without the need for address sharing
>    mechanisms that give rise to the issues identified herein.  In the
>    short term, maintaining growth of IPv4 services in the presence of
>    IPv4 address depletion will require address sharing.

  Given the huge list of issues, I find it surprising to see that the
  document says "In the short term (...) IPv4 address depletion will
  require address sharing." The document should much more strongly argue
  for deploying IPv6 as the solution. It does in a few places, but I
  think the message bears repeating. Put it in the footer! :-)


Section 3., paragraph 3:
>    +------------------------------------------------+--------+---------+
>    |                  Issue                        |  1st  |  3rd  |
>    |                                                |  party | parties |
>    +------------------------------------------------+--------+---------+

  It would be good for each issue in the table below to indicate which
  section discusses it in more detail. This is not at all clear from the
  headings of the subsequent sections. Add a column for this?


Section 5.1., paragraph 3:
>    A potential problem with dynamic allocation occurs when one of the
>    subscriber devices behind such a port-shared IPv4 address becomes
>    infected with a worm, which then quickly sets about opening many
>    outbound connections in order to propagate itself.  Such an infection
>    could rapidly exhaust the shared resource of the single IPv4 address
>    for all connected subscribers.  It is therefore necessary to impose
>    limits on the total number of ports available to an individual
>    subscriber to ensure that the shared resource (the IPv4 address)
>    remains available in some capacity to all the subscribers using it.

  Limits aren't the only way of handling this. You can also kill off
  established connections when the port space runs out. If you do this
  randomly, a user with many connections will be proportionally more
  likely to get hit, which is what is needed. The benefit of the "kill"
  scheme is that you can support a wider variety of sharing patterns
  compared to fixed limits.


Section 5.2.2., paragraph 2:
>    For example, the use of DNS SRV records [RFC2782] provides a
>    potential solution for subscribers wishing to host services in the
>    presence of a shared-addressing scheme.  SRV records make it possible
>    to specify a port value related to a service, thereby making services
>    accessible on ports other than the Well-Known ports.  It is worth
>    noting that this mechanism is not applicable to HTTP.

  HTTP as well as many other legacy protocols.


Section 13.1., paragraph 0:
> 13.1.  Abuse Logging and Penalty Boxes

  An addition to this section: There are web tie-ins into different
  black lists that some web site owners subscribe to which redirect
  clients to a URL that basically says "hey, your machine is infected."
  Sometimes, they even prevent their site from then working for that
  users, in order to "give incentives" to fix the problem. With address
  sharing, someone else's worm can hence interfere with my ability to do
  stuff. (And I already see this today behind the Nokia NAT, because
  some clown here has an infected Windows box on the intranet...)

State changed to In Last Call from Last Call Requested.

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 IP Address Sharing) to Informational RFC


The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document:
- 'Issues with IP Address Sharing'
  as an
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 2011-02-01. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The Document Shepherd is Julien Laganier, INTAREA co-chair. He
        has personally done a thorough review of the document. He
        believe the document is ready for forwarding to IESG for
        publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

        The document was given adequate reviews. The Document Shepherd has
        no concerns about the depth or breadth of these reviews.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        The Document Shepherd has no such concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues 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. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

        The Document Shepherd has no such concerns.

  (1.e) 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? 

There is WG consensus behind this document.

  (1.f) 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
        entered into the ID Tracker.)

        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.

  (1.h) Has the document split its references into normative and
        informative? 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
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document has split its references into normative and
        informative. There are neither normative references in an unclear
        state, nor downward references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

        The document has an IANA considerations sections that correctly
state that the document does not need IANA actions.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        There are no such sections.

  (1.k) 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 completion of IPv4 address allocations from IANA and the RIRs is
  causing service providers around the world to question how they will
  continue providing IPv4 connectivity service to their subscribers
  when there are no longer sufficient IPv4 addresses to allocate them
  one per subscriber.  Several possible solutions to this problem are
  now emerging based around the idea of shared IPv4 addressing.  These
  solutions give rise to a number of issues and this memo identifies
  those common to all such address sharing approaches.  Solution-
  specific discussions are out of scope.

    Working Group Summary

  The normal WG process was followed and the document as it stands now
  reflects WG consensus with nothing special worth mentioning.

    Document Quality

  The document was given adequate reviews. The Document Shepherd has
  no concerns about the depth or breadth of these reviews.