Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Jul 2005 14:33:02 -0700 (PDT)

Right.

Using bindings is a perfectly reasonable way of implementing this, and
people are free to do it.

But the mandate of the BEHAVE group is NOT to mandate specific
technologies for implementation. This is why the language in the
draft keeps it at a higher level (i.e., using "mapping" instead
of "binding").

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Saikat Guha
> Sent: Tuesday, July 19, 2005 14:11
> To: Senthil Sivakumar (ssenthil)
> Cc: Behave
> Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh
> 
> 
> On Tue, 2005-07-19 at 07:59 -0700, Senthil Sivakumar (ssenthil) wrote:
> > You could definitely have an
> > implementation that does not use any bindings, so the end 
> user could 
> > get a different address for every session
> 
> It is not as simple as that. What behave-udp currently requires is:
> 
> - you MUST get the same address for every "session" as long 
> as there is 
>   even one live session from the same internal endpoint.
> 
> behave-udp does not say what happens after all live sessions 
> timeout. you may or may not get the same address, say a 
> couple of hours after the last session expires. That is what 
> "bindings" proposal mandates. In particular, the binding 
> requirement translates to:
> 
> - you MUST get the same address for every "session" as long 
> as there is 
>   even one live session from the same internal endpoint. 
>   (same as behave-udp)
> - in addition, you MUST get the same address for a new 
> session initiated
>   within some time-window since the last live session expired.
>   (where the time-window is defined by the so-called binding-timer)
> 
> So it is not true that if you do not use binding then you get 
> a different address for every session (see the Linux mail earlier). 
> 
> The first and foremost concern everyone has -- that 
> concurrent "sessions" from the same internal endpoint all get 
> the same address -- is explicitly handled by both proposals. 
> 
> -- 
> Saikat
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 20 Jul 2005 06:11:01 -0700 (PDT)

> people are free to do it.

[suresh] This is the fundamental disconnect. Let me repeat for the nth time.
Binding is not not an implementation detail. Binding is a NAT resource, just as
a NAT Session is. Linux version of implementing a Binding is Linux
implementation detail.  

> draft keeps it at a higher level (i.e., using "mapping" instead

[suresh] The language in the UDP draft is not at a higher level. The language
in the UDP draft is the source of inconsistency and confusion. You are using
"mapping" at a high level instead of "Binding" to refer to idle timeout of "NAT
Sessions" in REQ-5? 

cheers,
suresh

> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: Bryan Ford <[email-masked]>
Date: Thu, 28 Jul 2005 03:43:12 -0700 (PDT)

> draft keeps it at a higher level (i.e., using "mapping" instead

If by "higher level" you mean "vague and nowhere explicitly defined", then I 
agree.  Judging from recent discussion there is still rampant confusion about 
which uses of the term "mapping" in the draft refer to something binding-ish 
and which uses refer to something session-ish.  At least the terms Binding, 
Session, and NAT Session have very clear definitions with well-established 
precedent; as far as I can tell mapping is just a verb.

Bryan

---

From: Saikat Guha <[email-masked]>
Date: Thu, 28 Jul 2005 03:49:11 -0700 (PDT)

On Thu, 2005-07-28 at 12:43 +0200, Bryan Ford wrote:
> This is why the language in the
> agree.

As far as I understand, draft-ietf-behave-nat-udp-03.txt line 247
defines it fairly explicitly.

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 29 Jul 2005 10:01:42 -0700 (PDT)

> defines it fairly explicitly.

[suresh] Use of the term "mapping" is inconsitent and far from clear throughout
the document. You had claimed in several of your e-mails that Maping is same is
Binding. Yet, the draft, right after line 247 says Mappign is not same as
Binding. So much for the definition matching your understanding. The same term
is used to mean NAt Session in REQ-5.

Further, In the mail dated 07/26, when asked what Mapping is, you said it can
be either Binding or NAT Session, depending upon implementation. That the term
carries different semantics depending upon implmentation and context of its use
is precisely the problem with the term. This is what Bryan is referign to as
vague. Below is the quote from 07/26 e-mail to jog your memory.

    Suresh:: > Is that a Binding or a NAT Session? 
    Sakat::  Depending on the implementation; it can be either. 

Now, the second half of bryan's e-mail, which you omitted in your response, is
really the crux. I will quote the text below for convenient reference. 

"At least the terms Binding, Session, and NAT Session have very clear
definitions with well-established precedent; as far as I can tell mapping is
just a verb."

Why not use terms that have clear definition, carry precise semantics and have
established precedence to describe BEHAVE requirements? That is really the
question. The terms "Binding" and "NAT Session" are consitent with earlier NAT
RFCs, implementation independent and adequate to describe BEHAVE requirements.
ford-behave-gen and sivakumar-behave-nat-tcp are testaments to that. Both these
drafts have used the terms Binding and NAT Session to derive BEHAVE
requirements. It is trivial to do the same wiht behave-udp. 

cheers,
suresh