Subject: [Mip6] More Comments on draft-petander-mip6-mbb-00.txt

From: Christian Vogt <[email-masked]>
Date: Fri, 04 Nov 2005 13:33:23 +0100

Hi Henrik, hi Eranga,

something caught may attention ex post.  In section 2, you say:

    If MN changes its binding when sending BU (instead of waiting for
    BA), it will drop all packets CN sends using the old CoA, i.e.
    packets CN has sent before it received BU: MN compares the CoA in its
    binding update list with (new CoA) with the old CoA used as
    destination address in IPv6 header, and drops the packets due to the
    mismatch. This is not necessarily the case for route optimized MN -
    CN communication due to the more relaxed checks, but will cause MN to
    drop all packets tunneled by HA due to the more strict checks on the
    tunnel header. MN can avoid this by changing its binding update list
    entry for CN to use new CoA only when receiving BA. However, during
    the time period between CN receiving BU and MN receiving BA, MN is
    likely to send packets to CN using the old CoA. CN will drop these
    packets due to the mismatch with the CoA in its binding cache and the
    one in the packets.

To my knowledge, the mobile node can always receive packets sent to a 
different CoA than the one registered in its binding-update list (BUL). 
  For route-optimized packets, this is defined in section 11.3.3, RFC 
3775.  For packets tunneled from the HA, it's said in section 6.8, RFC 
3776 (note that this section also pertains to payload packets):

    Step 3.  This matches the policy required for this security
    association (source = any, destination = home address).

This said, I think you need changes to neither BUL nor binding cache if 
the MN registers the new CoA directly in the BUL and sends subsequent 
packets from the new CoA.

Regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

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

---

From: Henrik Petander <[email-masked]>
Date: Mon, 7 Nov 2005 12:02:27 +1100

Hi Christian,

Thanks for your comments.

> different CoA than the one registered in its binding-update list (BUL).

RFC 3775 does not prohibit this. However, in practice this is not the
case based on my experiences with MIPL1 and MIPL2. Other
implementations may do things similarly.

> 3775.

Yes, this is true and also stated in the draft (more relaxed checks
with RO). Unfortunately, the implementations I have been working with
make a more strict check and match the CoA in incoming packets with
the CoA in BUL. This leads to MN dropping the incoming packets.

> For packets tunneled from the HA, it's said in section 6.8, RFC

RRFC 3776 focuses on IPsec processing of packets. IPv6 tunneling is a
separate system and  AFAIK the MIPv6 specification does not define how
tunneled packets are processed in MN in addition to specifying that MN
MUST check that the destination address of the original packet is a
home address. Thus the handling of incoming tunneled packets depends
much on the implementation.

 An easy way to do the tunneling is to use generic IPv6 tunneling
code. If MN uses generic IPv6 tunneling and demultiplexes incoming
traffic to tunnels based on the addresses in the tunnel header, it
will drop packets coming to an "old" CoA, since the tunnel has been
updated to use a "new" CoA. This was the case for MIPL at least. With
such point to point tunnels you need to take care that the switching
to a new CoA does not disrupt traffic.I would be interested to know if
also other implementations have this feature/problem?

- Henrik

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 8 Nov 2005 04:38:27 +0900

Dear all,

I've read the draft and I'm thinking how much the mechanisms to be
developped by Monami6 (multiple CoAs registration) could be useful for
the scenario described in draft-petander-mip6-mbb. 

Also, I'm wondering how much the solution for the problem described in
there could apply to NEMO Basic Suport. I think that now all solutions
should apply to both MIP6 and NEMO Basic Support.

On the overall, I wonder where this work should be happening and how
much of this work could be taken by Monami6.

Thierry

---

From: Henrik Petander <[email-masked]>
Date: Tue, 8 Nov 2005 10:12:16 +1100

Hi Thierry,

> should apply to both MIP6 and NEMO Basic Support.

The draft applies equally to the NEMO basic protocol, and I actually
tested it using our NEMO implementation. It may also apply to other
extensions of MIPv6 such as HMIPv6.

> much of this work could be taken by Monami6.

Mip6 wg would be a good choice IMO, if make-before-break handoffs fit
into the scope of the wg and there is enough interest there.  Monami
might be a good option as well, if there is interest to pursue better
handoff performance for multihomed MNs and MRs.

-Henrik

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 8 Nov 2005 00:17:29 +0100

Hi,

> handoff performance for multihomed MNs and MRs.

Performance issue is something I like to discuss during tomorrow's  
session. I think it is important to have mechanism to handover  
between interfaces in an efficient way. Especially, if two interfaces  
are available at the same time, it should be possible to have  
handover without any loss of packets.

Nicolas

> Monami6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/monami6
>

---

From: "Yong-Geun Hong" <[email-masked]>
Date: Tue, 8 Nov 2005 08:58:18 +0900

Hi..

I am also interesting in this Make-Before-Break handoff with multiple
interfaces. 
I think that MBB handoff gives efficient handoff solution.

But, I have one question.
Is it possible to use MBB handoff only in a mobile node with multiple
interfaces?
Refer the following URL, and Section 3.2 Case : Single Interface with Make
Before Break.
http://pec.etri.re.kr/~yghong/draft-hong-dna-if-l2-00.txt

Although, that draft had no interest in DNA WG at that time, I think that
MBB handoff must be 
fully considered. And I think that MBB handoff is possible in a mobile node
with a single interface. 

In CDMA network, L2(Layer 2) MBB handoff in a mobile node with a single
interface is possible but
L3(Layer 3) MBB handoff is impossible because PPP connection is used between
PDSN and a MN.

In 802.16 network, L2 MBB handoff and L3 MBB handoff in a mobile node with a
single interface
are also possible. (If some policy and operations issues are permitted)

Thanks..

Yong-Geun..

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nicolas Montavont
> Sent: Tuesday, November 08, 2005 8:17 AM
> To: [email-masked]; Monami6 WG
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Monami6] More Comments on draft-petander-mip6-mbb-00.txt
> 
> 
> Hi,
> 
> >> Also, I'm wondering how much the solution for the problem 
> described 
> >> in there could apply to NEMO Basic Suport. I think that now all 
> >> solutions should apply to both MIP6 and NEMO Basic Support.
> >>
> >
> Performance issue is something I like to discuss during 
> tomorrow's session. I think it is important to have mechanism 
> to handover between interfaces in an efficient way. 
> Especially, if two interfaces are available at the same time, 
> it should be possible to have handover without any loss of packets.
> 
> Nicolas
> 
> >
> > -Henrik
> >

---

From: Christian Vogt <[email-masked]>
Date: Thu, 10 Nov 2005 09:18:47 +0100

Hi Henrik.

 >> To my knowledge, the mobile node can always receive packets sent to
 >> a different CoA than the one registered in its binding-update list
 >> (BUL).
 >

So it's an issue with existing implementations.  OTOH, I think there is 
agreement that RFC 3775 supports MBB handoffs with multiple interfaces 
quite fine...

Skipping...

 > updated to use a "new" CoA. This was the case for MIPL at least. [...]

I see, this *is* an issue, yes.

Regards,
- Christian

Henrik Petander wrote:
>> To my knowledge, the mobile node can always receive packets sent to
>> a different CoA than the one registered in its binding-update list
>> (BUL).
> 
> 
>  separate system and  AFAIK the MIPv6 specification does not define
> how tunneled packets are processed in MN in addition to specifying
> that MN MUST check that the destination address of the original
> packet is a home address. Thus the handling of incoming tunneled
> packets depends much on the implementation.
> 
>  to a new CoA does not disrupt traffic.I would be interested to know
> if also other implementations have this feature/problem?
> 
> - Henrik