LSN A+P Q&A

In A+P mode, what is the need for CPE to send NATTed packets to the provider box (PRR or LSN)?
This is mainly for security reasons.  You can't assume that CPE are all good citizens. Here, one public IP address is assigned to multple CPE devices with different port range for source port NAT.  If the rogue CPE or misbehaving CPE uses ports for source port NAT beyond assigned values, it can distrub the traffic of some other CPE.  To ensure that this does not happen, all packets are sent to the centralized box in provider network.  Provider network validates the source ports of outgoing connections of the CPE and transmits out onto the Internet only if source port is one of the ports assigned to the CPE box. Provider box (PRR) maitains the table with IPv6 address (which is used as source IP of tunnel by the CPE ) and the allocated ports.  This table would be referred by the PRR to validate the source ports of the connections.

Can rogue CPE mount DOS attack on other CPE if the rogue CPE knows the IPv6 address and the port allocations of the victim CPE?

In theory, it is possible.  Rogue CPE may not be able to get hold of the traffic of victim CPE, but it can mount DOS attack.  Rogue CPE can disable some portions of victim CPE communication by using all ports.   I believe it is necessary that each CPE authenticates itself to the PRR before sending the traffic over the IPv6 tunnel.  It is not there today, but it is natural expect in my view.

One proposal I saw can make this DoS attack difficult.  If the PRR assigns the random ports to the CPE rather than fixed range, then it makes it difficult for rogue CPE to determine the  exact pots used by other CPEs.

Havind said that, a rogue CPE can, it it wants, mount DOS attack such a way that it can use up the ports of different CPE devices if it knows the IPv6 addresses.  So, it is good to have authenticaiton support bulit into creating the IPv6 tunnel.

I personally belive that IPsec IPv6 tunnels with IKEv2 would be the right fit. It increases the processing requirements, but it is secure.  IPsec allows transport of IPv4 packets over IPv6 tunnel in addition to IPv6 packets in IPv6 tunnel.  It provides not only authentication of the CPE device, but also secures the traffic between CPE device and the PRR.  It also can retain the QoS characterstics of the differnet packets between CPE and LSN.  If data security is not required, ESP with Authentication can be used which is less expensive from computation processing is concerned on the LSN device.

In 3GPP,  Femto Access Points (CPE devices) already have IPsec tunnel with IKEv2 to SeGW (ePDG).  Same tunnel can be used to transport IPv4 packets to the ePDG, if ePDG is equipped with the PRR & LSN functionality.

Are there any CPE devices or Smart phones supporting LSN & A+P functionality?

I don't have this information.  I saw some internet postings from Android based phone vendors asking about LSN.  So, I beleive it is in vendors radar, but not sure whether anybody has solutions in the market. As I indicated in my last post, Cisco has LSN functionality on service provider side  in their portfolio.  A10networks also has some service provider boxes supporting LSN. 

IPv6 - finally? Is LSN becoming transition technology?

Some articles in recent past is indicating that IPv6 is being adopted by vendors and service providers.

This article here indicates that Cisco has LSN solution for service providers.  As described here, LSN provides transition from IPv4 to IPv6 gradually.  I like the phrase used by Cisco in the article on IPv6 transition -  preserve, prepare and prosper.  Preserve the Ipv4 infrastructure while preparing for IPv4/IPv6 transition (LSN) and then move to Prosper phase with complete Ipv6.

This article here says that comcast is going to test LSN in Q3 2010.  This is very good news that IPv6 is being adopted by service providers.

As I indicated in my previous article LSN itself is not good enough for some subscribers. A+P addition in my view is very much required.

I am not seeing much activity in CPE device market supporting A+P functionality in it.  I guess it is natural that it would happen soon.  I also see some internet drafts which add some additional options in DHCPv6 and PPPv6 to assign PRR address.  I am still yet to see any internet drafts on allocate/de-allocate public IPv4+port pairs dynamically.  If anybody has come across any specifications on this, please comment.

Large Scale NAT with DS-Lite & A+P

Dual Stack Lite, Address plus Port assignment to CPE devices by ISPs are two most important mechanisms being adopted by ISPs to provide connectivity to IPv4 internet to smart phones, CPE devices in Residential markets and Femto CPEs.

Dual Stack Lite and A+P mechanisms are being done to ensure that IPv6 transition is smooth as Internet becomes Ipv6 addressable over time.

ISPs are facing shortage of public IPv4 addresses. Demand was increased with popularity of Internet in general and in particular the explosion growth of smart phones. Many ISPs are no longer in position to provide the dynamic public IP address to the CPE devices and smart phones. Note that CPE devices and smart phones have become always-on. So dynamic IP address is really becoming static.

Until world moves to the Ipv6,  only way is sharing of IPv4 address across multiple subscribers.

Many mobile service providers are only giving the private IP address to the smart phones and ISPs  This trend is continuing even for CPE devices with its explosive growth.   ISPs maintain mega NAT boxes which translate the traffic from CPE and smart phones with certain number of public IP addresses.  CPE devices already do their own NAT between IP addresses it assigns to local machines in the LAN with the IP address provided by the ISP.  Due to this, there is double NAT.  Though it works in majority of cases, there are some limitations which could be problematic for end customers, hence to the ISP business.

•  Connectivity could be lost if dynamic  private IP address is assigned by the ISP is part of the private subnet the CPE is configured to assign to the local machines.
• Though not a big concern immediately,  Bigger ISPs might have customer more than the private IP address space. If one goes with 10.x.x.x network, then ISPs might provide address to 2^24 subscribers.  With smart phones in the range of 120M in 2012,  it is a possibility that ISPs might even don't have many unique private IP addresses to assign.
• Applications requiring special ALG will not work if both NAT devices (CPE as well as Carrier NAT) don't support the ALGs.   ISP Carrier NAT box may not entertain proprietary ALGs or may not have many ALGs.
• Two internal machines that need to communicate among themselves (peer-to-peer) applications may not work in double NAT scenarios (hair pin scenarios).
• Many peer-to-peer applications expect same IP and Port to be used for SNAT even though destination machines are different.  If not supported by Carrier NAT, many peer-to-peer applications may not work.

Large Scale NAT  (LSN) solves some of above limitations by doing NAT at only one place. In this model,  CPE is given the IPv6 address on its WAN interface.  If IPv6 machines are communicating with IPv6 destinations, then there is no IPv4 involved and it works fine.  If IPv4 machine in private network is communicating with public Ipv4 network in the Internet, then these packets are tunneled to the LSN box sitting in the provider network.  Ipv6 is used to tunnel IPv4 packets between CPE and LSN.  LNSN box in Provide network does the NAPT.   LSN eliminates double NAT.  LSN also takes care of overlapping private IP addresses among multiple subscribers by keeping the IPv6 tunnel end point address as one of the identification parameter to map the NAT entry.  It still has problems related to ALGs.  That is, if the LSN does not support ALGs for some applications, then these applications never work.  Also, LSN need to be high performing box with respect to throughput,  latency and jitter.  Though this can be solved by multiple LSN boxes, but ALG problems are too big for adoption of this technology. Also, if any application needs to be hosted, this becomes tough as port forwarding is controlled at Carrier NAT rather than the CPE gateway as we all normally accustomed to.

A+P (Address Plus Port) specifications provides the flexibility of doing NAT with CPE.  In this case, multiple CPEs are given with same public IP address, but with different ports.  CPE NAT is only expected to use assigned ports for source port NAT.  CPE can decide not to do NAT for some connections and in which case LSN in provider network would do the NAT.  Based on different people experience, I believe only few ports are necessary by the CPE due to feature called 'Dense NAT'.  That is, same source port can be used across multiple connections as long as 5-tuple is different across the connections on the external realm. Some web sites using AJAX may make multiple connections at the same time. I believe there are some sites which make almost 60+ connections at a time.  128 port range is good enough for many cases.  What it means is that, even without LSN, same IP address can be used across 128 subscribers assuming each subscriber requires 128 ports.  With A+P alone, the ISP can increase his customer base 128 times with the public IPv4 addresses the ISP has.  Since NAT is done at the CPE, all the facilities as in current CPE boxes are possible. It can have port forwarding feature,  each CPE can have its own ALGs and each one can have port triggering feature.  Having said that, it has its own limitations - IPsec without UDP NAT traversal does not work.  ICMP Echo Request/Reply would need to be taken care little bit more carefully as it does not have port concept.

I believe Comcast is in advanced stages of deploying LSN. Many ISPs would be requiring to install some kind of solution very soon.  In my view, the solution would be combination of LSN and A+P.  ISPs will differentiate subscribers using following subscriptions.

• Subscribers requiring static public IP address.
• Subscribers hosting any servers on standard ports which are expected to be reached via their own Domain name.
• Subscribers requiring dynamic public IP address.
• Subscribers hosting servers on standard ports with DDNS.
• Subscribers with shared public IP address and dedicated ports for SNAT.
• Subscribers hosting games or hosting servers on non-standard ports.
• Subscribers with shared public IP address and shared ports (LSN).
• Subscribers just requiring outbound access.

CPE devices and Smart phones require some support if they intend to take advantage of LSN and A+P.  When I was going through the specifications,  I had one doubt on why the CPE NATted packets need to go through the IPv6 tunnel to the PRR (Port Range Router).  I think the reason why they need to go is to ensure that the CPE device really did NAT with the IP address and Ports that were allocated to it by the PRR. It is required to ensure that CPE devices are behaving well and does not damage the connectivity of other CPE devices.

Let us see the kind of changes required in CPE devices.

Features expected in CPE:

• CPE must support IPv6 addressing on its WAN Interfaces. 
• Learning of LSN IPv6 address using DHCP extensions, PPP extensions Or CPE should have facility to provide static configuration.
• In case CPE supports A+P, it should also learn the public IPv4 address and Port range(s)  from DHCP, PPP or via local configuration.  In some cases, more port ranges also can be requested dynamically when the ports are getting exhausted.  If it does not require any port ranges, it should be able to free them back to the PRR.
• CPE must be able to provide IPv6 addresses to the IPv6 capable hosts in its internal network.
• CPE must be able to provide IPv4 private addressing to the local hosts in its internal network.
• CPE must be able to tunnel packets from private IP hosts to the LSN in provider network.
• In case of A+P, it should have intelligence to figure out which connecting to be NATTed at the CPE and which one are allowed to be done at the LSN.
• CPE optionally also can support providing the A+P to the local hosts if they are A+P aware. In which case, CPE also acts as local PRR.

Features expected in PRR:

• It should be able to do Address+Port Management via signaling protocols (DHCP, PPP or web based management).
• It should be figure out the packets that needs to go through LSN and if so, send those packets to LSN.
• It should ensure that the packets are NATted by CPE with its delegated addresses and ports. If not, it should discard the packets.
• It should provide facilities WCCP protocol for security checks (AV, AS,  IPS etc..).
• It should terminate IPv6 tunnels and should be prepared to make Ipv6 tunnels to the LSN.
• It should be scalable:  Good algorithms to 
• Search tunnel for incoming packets from the CPE.
• Search Address+Port based entries for packets coming from Internet to identify the CPE device and hence the tunnel.

Features expected in LSN:

• It should be able to terminate large number of tunnels.
• It should be able to maintain large number of NAT entries.
• It should be able to work with CPE devices having same private IP address space.
• It should be able to stateful failover if device fails.
• It should support popular application ALGs such as:
• FTP, RTSP, SIP, H.323. MGCP,  PPTP, L2TP and more..

I hope it helps.