Subject: AW: [NSIS] NATFW and multihoming

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 5 May 2006 16:45:39 +0200

Hi Matthias, 

> Hi,
> 
> thanks for the answer, more questions below.
> 
> On Thursday, 2006-05-04, Hannes Tschofenig wrote:
> > Matthias Friedrich wrote:
> 
> [...]
> > Let us look at the picture and assume that  MB1 and MB2 are 
> NATs and the 
> > network is multi-homed.
> 
> >              +----+
> >    DR -------|MB1 |\
> >        \     +----+ \  //---\\
> >         \            -|       |-- DS
> >          \             \\---//
> >           \  +----+       |
> >            --|MB2 |-------+
> >              +----+
> >
> >         private          public
> 
> 
> > The initial REA allocated a NAT binding at MB1. Now, MB1 goes down.
> 
> > The main question now depends on how data traffic is 
> routed. If the REA 
> > routing changes and travels through MB2 then everything 
> will be fine 
> > again at the next refresh interval. The REA will hit MB2 
> and will create 
> > a new NAT binding.
> 
> OK, so the DR sends REAs regularly to keep the NAT binding alive, as
> per section 3.8.3.

Yes, that's the idea of the soft-state mechanisms. 

> From reading [1] I got the impression that CREATE
> (or rather RESPONSE?) could also keep the NAT binding alive. See their
> section 8, state SESSION, which doesn't send refresh REAs.

A successful CREATE/RESPONSE message run refreshes state. The same is
true for REA/RESPONSE messages. 

> 
> > If traffic sent by the DR travels to MB1 (which does not 
> work anymore) 
> > then both data traffic and NSIS signaling traffic will disappear.

That's the difficult part with the roles. To be precise the DR would
change its role to a DR when it sends traffic. 

If the all packets travel to MB1 (which is down) then nothing works. 

> 
> > What do you think?
> 
> This means the DR has to check all RESPONSEs to its REA messages and
> if the external address has changed, it has to tell the DS the new
> address via some signaling mechanism (as Martin wrote in his reply).
> One way would be to use the application level signaling if 
> that's still
> available. The other would be to send an NATFW NOTIFY to the DS which
> contains the new external address.

Right.

Note that there is nothing special we introduced with NSIS here.
You mentioned the mobility draft. There, you also have some signaling
exchanges if IP addresses change (for whatever reason). 

> 
> For the latter method, an optional "Data Terminal Information Object"
> would have to be added to NOTIFY. Do you think the use case 
> is important
> enough to justify this change?
That's a good question. 

> 
> Even if the NOTIFY is modified, it's not guaranteed that the DS can
> redirect the data traffic. For example, it's not easily possible to
> change the destination address of a TCP session on the fly.

It is easy to redirect the data traffic. However, the implications
depend on an IP address change depends on a number of things. A mobility
protocol that deals with IP address changes without impacting the
high-layer protocols might be a possibility. 

Ciao
Hannes

> Thanks for your answers,
> 	Matthias

Ciao
Hannes

PS: Are you currently working on an implementation of the draft? 

> 
> [1] 
> http://www.ietf.org/internet-drafts/draft-werner-nsis-natfw-ns
> lp-statemachine-02.txt
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Matthias Friedrich <[email-masked]>
Date: Mon, 8 May 2006 09:40:47 +0200

Hi,

On Friday, 2006-05-05, Tschofenig, Hannes wrote:
[...]

> Yes, that's the idea of the soft-state mechanisms. 

Good, then the NATFW state machine draft should be fixed, that's what
confused me a bit. The NR's SESSION state needs another timer that sends
refresh REAs regularly.

[ signaling of a changed external address ]
>> would have to be added to NOTIFY. Do you think the use case is
>> important enough to justify this change?

> That's a good question. 

It's not like I absolutely wanted this feature, I just got stuck on that
case and wondered if NATFW could help to solve this.

[...]
> PS: Are you currently working on an implementation of the draft? 

That's not completely decided yet, but it could be part of my diploma
thesis. At the moment I'm trying to get into the topic, reading some of
the NSIS drafts and related work.

Cheers,
	Matthias

000375-Qb
	for [email-masked]; Mon, 08 May 2006 03:41:03 -0400
Date: Mon, 8 May 2006 09:40:47 +0200
From: Matthias Friedrich <[email-masked]>
To: [email-masked]
Subject: Re: [NSIS] NATFW and multihoming
Mail-Followup-To: [email-masked], [email-masked]
Cc: [email-masked]

Hi,

On Friday, 2006-05-05, Tschofenig, Hannes wrote:
[...]

> Yes, that's the idea of the soft-state mechanisms. 

Good, then the NATFW state machine draft should be fixed, that's what
confused me a bit. The NR's SESSION state needs another timer that sends
refresh REAs regularly.

[ signaling of a changed external address ]
>> would have to be added to NOTIFY. Do you think the use case is
>> important enough to justify this change?

> That's a good question. 

It's not like I absolutely wanted this feature, I just got stuck on that
case and wondered if NATFW could help to solve this.

[...]
> PS: Are you currently working on an implementation of the draft? 

That's not completely decided yet, but it could be part of my diploma
thesis. At the moment I'm trying to get into the topic, reading some of
the NSIS drafts and related work.

Cheers,
	Matthias

---

From: "Henning Peters" <[email-masked]>
Date: Mon, 8 May 2006 13:09:32 -0400 (EDT)

Hi Matthias,

> confused me a bit. The NR's SESSION state needs another timer that sends

The NR's tg_REA will result in REA_WAITRESP state, and if a successfull
response is received, in REA state (not SESSION).

The REA state defines REFRESH timers:
   -----------
   State: REA
   Entry: ResetCounter(REA);
          StartTimer(REFRESH);
   Exit : StopTimer(RESPONSE);
          StopTimer(REFRESH);
   -----------
<<<
http://www.ietf.org/internet-drafts/draft-werner-nsis-natfw-nslp-statemachine-02.txt

> the NSIS drafts and related work.

Great!

Henning Peters