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

[Behcet Sarikaya <[e-mail]>]

Hi Med,

I realize that you published a revision with the A+P reference. However, I
believe A+P is a problem for address sharing with its own solution, i.e.
the port range is the host id.

I would favor removing Sec. 4.6. Anyway you have not been exhaustive on the
solution space.

Regards,

Behcet

On Thu, Feb 14, 2013 at 12:51 AM, <[e-mail]> wrote:

> **
> Hi Behcet,
>
> I'm aware of that context but the problem is that I don't have a good
> reference to cite for it.
> http://tools.ietf.org/id/draft-schott-fmc-requirements-02.txt would be a
> good reference to cite but unfortunately the port set section was removed
> in the last version
> http://tools.ietf.org/html/draft-schott-fmc-requirements-04.
>
> Saying that, I really think having one example to cite is sufficient. No
> need to have an exhaustive reference list.
>
> Thanks.
>
> Cheers,
> Med
>
>  ------------------------------
> *De :* Behcet Sarikaya [mailto:[e-mail]]
> *Envoyé :* mercredi 13 février 2013 20:09
>
> *À :* 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,
>
> I think that email discussions we had on this issue in fmc list last year
> will provide good context in these discussions, please remember them.
>
> See inline:
>
> On Wed, Feb 13, 2013 at 11:16 AM, <[e-mail]> wrote:
>
>> **
>> 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]> 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.
>>
>>
> If Section 4.6 applies to A+P, there is no need for such a text, just say
> Use A+P and give the reference, right?
>
> Regards,
>
> Behcet
>
>