[Int-area] AD review of draft-ietf-intarea-shared-addressing-issues

[Jari Arkko <[e-mail]>]

I have reviewed this draft.

This document is important and describes well the different issues 
associated with address sharing. I have asked for the IETF last call to 
be initiated.

However, I did have a number of smaller issues that I hope you will 
correct during the last call. The main issue I had was about what the 
document said about IKE NAT traversal, but there were a few other issues 
and some editorial issues as well.

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

This text is the abstract. Later in the introduction you note that 
growing IPv6 use is the ultimate solution for reducing pressure on 
address sharing. I think it would be nice to see one sentence about the 
same thing here in the abstract as well.

> In current deployments, one important and widely used feature of many
> CPE devices is the ability to open incoming ports (port forwarding)
> either manually, or with a protocol such as UPnP IGD. 

Reference and explanation of the UPnP IGD acronym is needed.

> If a CGN is
> present, the port must also be open in the CGN.  

opened?

> In current deployments, one important and widely used feature of many
> CPE devices is the ability to open incoming ports (port forwarding)
> either manually, or with a protocol such as UPnP IGD.  If a CGN is
> present, the port must also be open in the CGN.  The situation may be
> alleviated somewhat if the CGN architecture is composed of only one
> NAT level (no NAT in the CPE) as for DS-Lite, although a service
> provider operating this solution will still be required to offer some
> means for configuring incoming ports by their subscribers.  This may
> be either via a UPnP or NAT-PMP relay over a tunnelled direct
> connection between the CPE and CGN, or a web interface to configure
> the incoming port mapping on the CGN. 

I think this text could be improved. You need to make different points 
here.  One point is that when the NAT moves from a CPE to a CGN device, 
the service provider has less incentives and even technical 
possibilities to proivde the port opening capability. Another point is 
that if two devices (the home gw and the CGN) need to co-operate in 
order to do this, then a new protocol is needed.

> o Applications that do not use any port (e.g., ICMP) - where address
>   sharing solutions map subscribers to (private) IP addresses on a
>   one-to-one basis this will not be an issue, otherwise such
>   applications will require special handling - see Section 9 <http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-02#section-9> for
>   more discussion of this;
>   

I'm not sure I understand this. First off, Section 9 clearly states that 
special handling is required anyway. In addition, the nature of the 
mapping (one to one or something else) does not seem to impact the 
handling of ICMP, because no matter what the mapping is, it won't be 
used by that special handling code as an incoming ICMP uses just public 
addresses.

> For CGNs, subscribers will be dependent on the
> set of ALGs that their service provider makes available.  A
> service provider-based NAT may, or may not, support NAT-traversal
> for IKE [RFC3947 <http://tools.ietf.org/html/rfc3947>] for example. 

This seems incorrect. IKE runs on UDP, and RFC 3947 is about endpoints 
working through NATs. The RFC even specifically mandates a change of the 
IKE port number in order to avoid some older NATs that might "help" IKE 
by doing something that ends up being harmful.

In general, the draft seems to assume that ALGs are required. I think it 
would be fairer to say that they are required in some cases, and in many 
other cases end-to-end protocol mechanisms have developed to work around 
lack of ALGs, to the point of it being preferable to avoid any support 
in the NAT.

> Viewed from the content provider, a
>    subscriber behind a CGN geolocates to wherever the prefix of the CGN
>    appears to be; very often that will be in a different city, and
>    sometimes in a different country, than the subscriber.

Do we have evidence of real-life commercial ISP service with the NAT and 
the subscriber in different countries? I would think that is unlikely... 
just say "... in a different city than the subscriber".

> here balancing
>    is achieved by deterministically routing traffic from specific source
>    IP addresses to specific servers, sudden imbalances in load may be
>    experienced as address sharing is enabled for some of those source IP
>    addresses. 

I think that sudden changes due to enabling address sharing is a rather 
theoretical problem. Its not like a subscriber's address is suddenly 
used by a CGN. More likely, CGN address pools are taken from address 
space that is currently unused or at least not recently used, and that 
growth in the traffic from a CGN happens gradually, as more subscribers 
get added to it.

Jari