Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt

From: Keigo Aso <[email-masked]>
Date: Tue, 04 Dec 2007 09:22:24 +0900

Hi all,

Let me summarize the returning home approaches we have discussed so far.
Hopefully this would be used for the preparation for hearing Ryuji's
presentation tomorrow.

There are two cases on HA configuration we should consider. One is HA is a
router case, another is HA is a host case.
When HA is a router, as we all already understand, there is no issue because HA
can intercept packets for MN's HoA without Proxy NDP and MN can run NDP for own
HoA on the home link. 
Only needed for this is HA has to know that MN is at home in order to make the
home binding. Actually the current MCoA draft already introduced the solution
for this, which is MN uses 'H' flag in BU to notify that it is attaching to the
home link also toghether with the CoA for the foreign binding.

While, when HA is a host case, HA has to run Proxy ND for intercepting packets
for MN's HoA. So, in this case, MN can not notify L2 address to the HA. For this
case there is a approach which is MN sends BU including L2 address. This may be
useful for the case HA is a router.

Furthermore, there is another good approach for this case, which is using
another CoA in the home link. If MN can create a CoA in the home link which is
different from own HoA, it can register it with 'H' flag for making the home
binding to the HA. Therefore, HA can run Proxy NDP for MN's HoA, while MN can
notify L2 address by running NDP for this CoA. In this approach, its CoA could
be the address which is made from own home prefix(HomeCoA). While if there is
another prefix in the home network, it is used for making the CoA. When using
other prefix, it would need operational stuff for HA and other MNs on the home
link. 

Regards,
Keigo

On Sun, 25 Nov 2007 02:53:02 +0900
Ryuji Wakikawa <[email-masked]> wrote:

> Hi George and Vijay,
> 
> Question is whether we should support DSMIP in this document.
> It seems reasonable to support DSMIP.
> We can easily extend BID sub-option to cary both IPv4/IPv6 addresses.
> 
> regards,
> ryuji
> 
> 
> 
> On 2007/11/22, at 8:25, Vijay Devarapalli wrote:
> 
> > George Tsirtsis wrote:
> >
> >> 7) Interactions with DSMIPv6. I think at some point a new section  
> >> needs to be added to talk about interactions with DSMIPv6. Beyond  
> >> the obvious issue of whether MCoAs can include IPv4 CoAs etc the  
> >> MCoA draft includes some interactions with IKEv2
> >
> > I think the IKEv2 interactions are inline with what we decided for
> > DS-MIPv6 last week. Transport mode IPsec SA for the binding update,
> > and tunnel mode SAs updated either by MIPv6 (K flag) or running
> > IKEv2 again.
> >
> > and imposes some requirements to the use of
> >> alternate-CoA which may or may not conflict with DSMIPv6 (have not  
> >> checked that myself yet).
> >
> > In DS-MIPv6, the IPv4 CoA option is a new mobility option, not
> > related to the alt CoA option in RFC 3775.
> > draft-ietf-monami6-multiplecoa says the alt CoA option should not
> > be included whenever the CoA is carried in the BID mobility option.
> >
> > The BID option as defined in the draft currently seems to allow
> > only for an IPv6 address. I think, we need to extend the BID option
> > to carry an IPv4 or an IPv6 address.
> >
> > Vijay
> >
> > _______________________________________________
> > MEXT mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mext
> 
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mext

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

---

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 5 Dec 2007 11:15:01 -0800

Folks,

I think we should keep things simple and do the following.

Abandon the homeCoA idea because although it technically works, it is
also more complex. Instead we can define a BU format that indicates to
the HA that the MN is attached to the home link but it does not
de-register (i.e., bindings to foreign links are still maintained).
For example we could set CoA==HoA and Lifetime==infinite or some other
variant of this.

This seems to be the simplest approach since it does not impact the
pNDP operation of the HA i.e., If the HA was configured to run pNDP
(e.g., shared links) then it continues to do so; If the HA was not
configured to run pNDP (e.g., p2p links) then it continues to not run
pNDP.

Does anyone see a problem with this approach?

Regards
George

---

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 7 Dec 2007 09:24:21 -0800

Hi All,

Benjamin  pointed out off-line that setting the lifetime to infinite
may not be the best idea since the BU in the home link creates a hard
state binding (=bad!). He is of course right. The point of my earlier
e-mail, however, was to suggest that we drop the idea of homeCoA. If
the WG agrees with that, I trust the authors to come up with syntax
for the BU that provides the right semantics.

Thanks
George

---

From: Keigo Aso <[email-masked]>
Date: Sat, 08 Dec 2007 02:46:36 +0900

Hi George,

On Fri, 7 Dec 2007 09:24:21 -0800

> for the BU that provides the right semantics.
Looks OK for me also. I also think, in this BU, the MN should be able to set the
lifetime even when registering the home binding because the entry should be kept
by the consecutive BU from the MN in common with the foreign binding. And also,
the BU with CoA==HoA is rejected by the HA because HA in RFC3775 must silently
discard the BU if the care-of address appears as a home address in an existing
Binding Cache entry by reason that HA thinks this binding will create a loop in
BCE (HoA --> HoA). Actually the authors already provided the simple way for this
purpose which is 'H' flag in BID option.

Regards,
Keigo