Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

________________________________
De : Behcet Sarikaya [mailto:[e-mail]]
Envoyé : mercredi 13 février 2013 18:01
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Suresh Krishnan; Brian Haberman; [e-mail]; [e-mail]
Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

Hi Med,

On Wed, Feb 13, 2013 at 10:43 AM, <[e-mail]<mailto:[e-mail]>> wrote:
Hi Behcet,

I have two comments:

* Host identification issue is valid for any address sharing mechanism.

I am not sure on A+P?
[Med] both A+P and NAT-based address sharing solutions are covered by rfc6269. host identifier is just a means to distinguish hosts under the same IP address. It does not matter how address sharing is implemented.

A+P requires point-to-point link, right?
This is why the introduction mentions already the following:

   As reported in [RFC6269<https://tools.ietf.org/html/rfc6269>], several issues are encountered when an IP
   address is shared among several subscribers.  These issues are
   encountered in various deployment contexts: e.g., Carrier Grade NAT
   (CGN), application proxies or A+P [RFC6346<https://tools.ietf.org/html/rfc6346>].

* RFC6346 is provided as an example of a solution making use of port sets. You are right, other solutions (than a+p) can be considered but having one pointer to a solution example is just fair. No need to be exhaustive here.

Again, I am not sure if Section 4.6 describes what A+P says?
[Med] That section says non overlapping port sets are assigned to hosts sharing the same IP address. The text does not describe if the shared address is also configured to those hosts or if there is a NAT in the host, etc. These are implementation variants. There is no value to provide such details in that section. Adding a ref to A+P is just fair. This does not preclude other contexts.

Regards,

Behcet