> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Behcet Sarikaya
> Sent: Thursday, February 14, 2013 9:37 AM
> To: [email protected]
> Cc: [email protected]; int-
> [email protected]
> Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-
> analysis
> 
> 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.

Except a remote server does not know the address is shared, nor what
port range is assigned to a user.  Lacking that, it does not have 
a solution.  With that, I would hesitate to rely on the system too
much, because changing number of ports per user would need to somehow
be coordinated with server logs -- which seems unlikely/impossible.

-d


> 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, <[email protected]> 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:[email protected]]
> 
>               Envoyé : mercredi 13 février 2013 20:09
> 
>               À : BOUCADAIR Mohamed OLNC/OLN
>               Cc : Suresh Krishnan; Brian Haberman;
draft-ietf-intarea-nat-
> [email protected]; [email protected]
>               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,
> <[email protected]> wrote:
> 
> 
> 
>                       Re-,
> 
>                       Please see inline.
> 
>                       Cheers,
>                       Med
> 
> 
> ________________________________
> 
> 
>                               De : Behcet Sarikaya
> [mailto:[email protected]]
> 
>                               Envoyé : mercredi 13 février 2013 18:01
>                               À : BOUCADAIR Mohamed OLNC/OLN
>                               Cc : Suresh Krishnan; Brian Haberman;
draft-ietf-
> [email protected]; [email protected]
> 
>                               Objet : Re: [Int-area] AD evaluation:
draft-ietf-
> intarea-nat-reveal-analysis
> 
> 
>                               Hi Med,
> 
> 
>                               On Wed, Feb 13, 2013 at 10:43 AM,
> <[email protected]> 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
> 
> 


_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to