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

From: Jari Arkko <[email-masked]>
Date: Tue, 18 Jan 2011 09:47:43 +0200

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

---

From: Matthew Ford <[email-masked]>
Date: Tue, 18 Jan 2011 12:08:50 +0000

Jari,

Thanks for the review. Some responses inline below:

On 18 Jan 2011, at 07:47, Jari Arkko wrote:

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

Agreed.

> Reference and explanation of the UPnP IGD acronym is needed.

Yes.

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

OK.

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

Sure, is this clearer?

"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 Universal Plug and Play
Internet Gateway Device (UPnP IGD) [ref].  If a CGN is present, the 
port must also be opened in the CGN. CGN makes subscribers dependent 
on their service provider for this functionality.

If the CPE and the CGN are required to co-operate in order for port forwarding 
functionality to work, protocol development will be required to provide an automated 
solution. If the CGN architecture is composed of only one NAT level (no NAT in
the CPE) as for DS-Lite, the service provider 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'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.
> 

You're right. It is sufficient to say 'Applications that do not use any port (e.g., ICMP) - will require special handling - see Section 9...'

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

Yes, I agree, bad example.

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

I'll add some text to the second bullet in Section 6 on p.12 and the first bullet in Section 6 on p.13 to clarify this.

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

I'm not aware of any concrete example, so you're proposed edit is fine for me.

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

Fair enough - I'll try to wordsmith a little to reflect your comment.

Thanks again for the review,

Mat

---

From: Jari Arkko <[email-masked]>
Date: Tue, 18 Jan 2011 14:27:59 +0200

Matthew,

> the incoming port mapping on the CGN."

Much better. Thanks.

> You're right. It is sufficient to say 'Applications that do not use any port (e.g., ICMP) - will require special handling - see Section 9...'

OK

> Yes, I agree, bad example.

OK

> I'll add some text to the second bullet in Section 6 on p.12 and the first bullet in Section 6 on p.13 to clarify this.

Good.

> I'm not aware of any concrete example, so you're proposed edit is fine for me.

OK

> Thanks again for the review,

Thanks for a very quick reply.

Jari