Issues with IP Address Sharing
Note: This ballot was opened for revision 05 and is now closed.
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...)
No Objection (2011-02-17)
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.
No Objection ()
No Objection ()
No Objection (2011-02-15)
Section 12 on Traceability refers to "the offending activity". Given the principle of innocent until proven guilty, I suggest "a particular activity".
No Objection (2011-02-16)
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"?
No Objection (2011-03-03)
No Objection (2011-02-17)
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. 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)
No Objection ()
No Record (2011-02-17)
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.