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

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

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.

Section 12 on Traceability refers to "the offending activity". Given the principle of innocent until proven guilty, I suggest "a particular activity".

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

  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)