[shara] Comments on the A+P issues (D. Thaler presentation)

[<[e-mail]>]

Dear Dave, all,

I have just read the slides your presented during the shara BoF (http://www.ietf.org/proceedings/09nov/slides/aplusp-3.pdf). 

1/ First of all, which a+p drafts your read to build your presentation? It seems that in your mind a+p is IPv4-centric solution which is not the case. We have several variants in which a+p is a means to prepare smooth migration to IPv6 while offering both **stateless** IPv4 sharing address and also **stateless** IPv4-IP6 interconnection. In those schemes, IPv4 connectivity services are delivered even using an IPv6-only network.

Furthermore, having your slides the architecture reference you used to sketch these issues would be useful. 

2/ Below some comments:

- In slide 2 you mention that the presentation focuses on issues specific to a+p. This is not correct since what has been mentioned in slide 6, 7, 8, 9, and 10 are common to all IP address sharing architecture. Please refer to http://tools.ietf.org/html/draft-ford-shared-addressing-issues-01.

Slide 3: Except the rhetoric problem which can be solved by a rhetoric answer too: we don't use unicast addresses but anycast ones!. Seriously speaking, I don't see any issue there since we don't use the shared IPv4 address as "identifier" but as a "locator". In the solution space, we have various implementations of the identifier: private IPv4 address, IPv6 address, etc. How doing so is a **big change** to the IP model? 

- Slide 4: these issues apply for SPs who want to migrate their to a full a+p solution which is a wrong strategy IMO. As far as we are concerned, we don't want to touch our legacy customers. We are targeting new customers with new devices (behind a CPE or directly connected). When a port restricted CPE is used, applications and end hosts *** do not *** need to be port range aware. If a+p is to be activated in a host, the mode you described with a NAT may be an implementation choice as described in http://tools.ietf.org/html/draft-boucadair-port-range-02#section-3.3.2, but this is not a recommendation.

- Slide 5: The use case you describe is not applicable for residential fixed deployment model. I fully agree that the roaming issue should be considered for mobile.

- Slide 6: This issue is the same as per ds-lite CGN, please refer to http://tools.ietf.org/html/draft-ford-shared-addressing-issues-01#section-6. The PRR has to use the ICMP identifier as a destination port number. ICMP queries can be then delivered to  appropriate port restricted device among those sharing the same address. The unsolvable issue (with the current ICMP version) is that you can not issue an ICMP request a device with shared address towards another device with a shared address. This issue is valid for both a+p and also when two NAT levels are in the path.

- Slide 7: Where is located "the same link" you are talking about? Note that this issue is the not specific to a+p.

- Slide 8: Be careful, I can change all "a+p" occurrences with "IPv6" and then present it to you as an argument to not move to IPv6 and stay with a NAT444 model which is not naturally the more voluntary approach to migrate to IPv6. BTW, we need to avoid adding complexity to systems which are supposed to be transition solutions, which is not an easy task. For these reasons, we proposed the IPv6 variant of a+p  for those SPs who don't want to have CGNs-only solution in their networks (i.e., reduce the amount of stateful devices) and who believe that IPv6 is the only perennial solution to solve address exhaustion.

- Slide 9: Another yet common issue to all address sharing solutions.

- Slide 10: Another yet common issue to all address sharing solutions, please refer to http://tools.ietf.org/html/draft-ford-shared-addressing-issues-01#section-11.1. Solutions have been elaborated in http://tools.ietf.org/html/draft-bajko-pripaddrassign-02#section-2. BTW, I'd like to see an example of TCP attack (not DNS one since it is UDP ;-)) which is solved by the port randomisation (since for TCP you sill need to guess the TCP sequence number in particular, which is hard to do compared to the port number). 

- Slide 11: No issue is described there. I failed to get the point: do you think that having stateful devices is more robust than stateless ones? That number of customers that will be impacted by the failure of a per-session state device is less than its stateless counterpart?

- Slide 12: Authors of a+p proposal are all IPv6-defender:
==> see http://tools.ietf.org/html/draft-ymbk-aplusp-04#section-2.1
==> see http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04
==> see http://tools.ietf.org/html/draft-xli-behave-divi-01
Etc.

After reading these slides, I failed to see your message: 
- do you want us to update our documents to solve some of the issues you identified?
- do you want us to abandon a+p effort?
- do you want us to restrict the scope of the a+p solutions?
- ...


Cheers,
Med










*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************