Subject: [Monami6] Accept draft-wakikawa-mobileip-multiplecoa-04.txt as Monami6 WG Document

From: Thierry Ernst <[email-masked]>
Date: Thu, 27 Oct 2005 15:45:24 +0900

Dear all,

The WG has been formed with the following deliverable on the charter:

- A protocol extension to Mobile IPv6 (RFC 3775) and NEMO Basic
Support (RFC 3963) to support the registration of multiple Care-of
Addresses at a given Home Agent address [Standard Track].

Jun 05	  	Submit Multiple CoA Registration to IESG

Chairs of the Monami6 WG would like to propose to move
draft-wakikawa-mobileip-multiplecoa-04.txt has the proposed solution for
this deliverable, and we are therefore seeking consensus of the Monami6
WG. We would like the discussion to happen from now on the mailing list
and conclude it at next IETF meeting in Vancouver.

Monami6 Chairs,
Nicolas & Thierry

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

---

From: "Junghoon Jee" <[email-masked]>
Date: Thu, 27 Oct 2005 15:56:58 +0900

Hello,
For clarification, is this a consensus call to making that draft as WG draft
? or
Just to bring the discussion to happen about the topic about "Multiple CoA
Registration" ?

Thanks,
Junghoon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thierry Ernst
Sent: Thursday, October 27, 2005 3:45 PM
To: ml-ietf-monami6
Subject: [Monami6] Accept draft-wakikawa-mobileip-multiplecoa-04.txt as
Monami6 WG Document

Dear all,

Monami6 Chairs,
Nicolas & Thierry

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 27 Oct 2005 16:31:37 +0900

Dear JungHoon,

> For clarification, is this a consensus call to making that draft as WG
> draft? or

Yes. Actually, this draft is one of the foundation behind the set up of
the Monami6 WG.

> Just to bring the discussion to happen about the topic about "Multiple
> CoA Registration" ?

Thierry.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Thierry Ernst
> Subject: [Monami6] Accept draft-wakikawa-mobileip-multiplecoa-04.txt
> as Monami6 WG Document
> 
> 
> 
> 
> Dear all,
> 
> draft-wakikawa-mobileip-multiplecoa-04.txt has the proposed solution
> for this deliverable, and we are therefore seeking consensus of the
> Monami6 WG. We would like the discussion to happen from now on the
> mailing list and conclude it at next IETF meeting in Vancouver.

---

From: "Junghoon Jee" <[email-masked]>
Date: Thu, 27 Oct 2005 16:37:52 +0900

Dear Thierry,
I got it. 

Thanks,
Junghoon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thierry Ernst
Sent: Thursday, October 27, 2005 4:32 PM
To: Monami6 WG
Subject: Re: [Monami6] Accept draft-wakikawa-mobileip-multiplecoa-04.txt
asMonami6 WG Document

Dear JungHoon,

Thierry.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Oct 2005 18:17:37 +0200

I'd first check whether there's any other proposal for multiple CoA
written, or about to be written.  Is there?

If not, then yes, I support this draft's idea to become a WG item.

And if the authors are open for discussion about the contents of this
document, then yes I support this document to become a Monami6 WG item.

The technical reason for supporting is that idea is simple: allow
multiple CoAs per one HoA.  That permits to eliminate the need to
configure two HoAs per one interface.  This can be helpful for reliability.

Alex

Thierry Ernst wrote:

> Monami6 Chairs, Nicolas & Thierry
> 
> _______________________________________________ Monami6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/monami6

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 27 Oct 2005 14:22:27 -0700

> and conclude it at next IETF meeting in Vancouver.

in general, I agree with the draft. it should be made
a WG document.

but it needs some work. here is one of the issues.

when a mobile node reverse tunnels a packet to the
HA, the HA performs a number of checks, which include
checks on the outer source address (CoA). sometimes
the tunnel decapsulation is done by IPsec code on
the HA. the tunnel mode IPsec SA is typically keyed
on the home address, but the CoA is stored in the
SPD/SAD entries. we could store multiple CoAs in the
binding cache, but it is not a standard IKEv2/IPsec
practice to store multiple outer tunnel source
addresses. we need to figure out a way to make this
work.

other minor issues.

1. the use of a flag in the binding update to
indicate multiple CoA registrations. perhaps we could
use a mobility option. flags are scarce.

2. do we need to really extend DHAAD? we can have
some kind of a reject status in the BAck if the HA
does not support this option. or have the HA echo
something back if it supports multiple CoA
registration and has processed the BU successfully.

3. I dont understand the need for a BID. the draft
says

>          The BID is an identification number used to distinguish
>          multiple bindings registered by the mobile node.  Assignment of
>          distinct BID allows a mobile node to register multiple binding
>          cache entries for a given home address. 

doesnt the HoA/CoA pair uniquely identify a binding?
do you want a unique identifier for a particular
binding even when the CoA changes? in that case why
not associate the interface with a particular binding?
maybe I am missing something.

---

From: Vidya Narayanan <[email-masked]>
Date: Thu, 27 Oct 2005 16:39:18 -0500

I have sent a separate posting with some comments on the draft. Since I have
some questions on the fundamental design choices on the draft, I am
reluctant at this point to say it should be a working group document.
 Thanks,
Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 27 Oct 2005 14:59:38 -0700

hello Thierry,

can you get the "Reply-To" for this mailing list
removed? it just drops everybody on the "to" and "cc"
list

Vijay

Vidya Narayanan wrote:
> I have sent a separate posting with some comments on the draft. Since I 
> have some questions on the fundamental design choices on the draft, I am 
>  Repl
> On 10/27/05, *Vijay Devarapalli* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Thierry Ernst wrote:
>      >
>      > Dear all,
>      >
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 28 Oct 2005 09:20:57 +0900

Done.
And I leave the answer to your comments to Ryuji.

On Thu, 27 Oct 2005 14:59:38 -0700
Vijay Devarapalli <[email-masked]> wrote:

> > I have sent a separate posting with some comments on the draft.
> > Since I have some questions on the fundamental design choices on the
> > draft, I am reluctant at this point to say it should be a working
> > group document.
> >  
> > Thanks,
> > Vidya
> > 
> >  Repl
> >      > - A protocol extension to Mobile IPv6 (RFC 3775) and NEMO
> >      > Basic Support (RFC 3963) to support the registration of
> >      > multiple Care-of Addresses at a given Home Agent address
> >      > [Standard Track].
> >      >
> >      > this deliverable, and we are therefore seeking consensus of
> >      > the
> >     Monami6
> >      >          The BID is an identification number used to
> >      >          distinguish multiple bindings registered by the
> >      >          mobile
> >     node.  Assignment of
> >      >          distinct BID allows a mobile node to register
> >      >          multiple
> >     binding

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 28 Oct 2005 09:32:07 +0900

Dear all,

To be clear, the purpose of this announcement is for the discusssion to
be happening, so this is quite good that this call for comments does
produce the expected comments. At least, we will be able to have a good
discussion on this point at Vancouver, so please express all your
concerns on the list from now until end of next week. So, of course
authors should be - and are - open for discussion.

Regarding Vidya comments, these are valid, but won't you think this
could be fixed in the draft ? If so, could Vidya clarify why she is
reluctant for this document to become a WG doc ? 

Thierry.

 On Thu, 27 Oct 2005 18:17:37 +0200

---

From: "Asanga Udugama" <[email-masked]>
Date: Fri, 28 Oct 2005 06:04:30 +0200

Hello,

I am also interested in some of the issues that were discussed related
to this draft. 

I think, the BID is a good thing to have as HoA/CoA pair is insufficient
in the case when a MN does a handoff. If not for the BID, the HA will
continue to think that the old binding is valid until the expiry. Is
this the purpose of having the BID?

I would also like to know whether this draft has been implemented. If
so, can I have some info?

Kind regards,
Asanga

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Vijay Devarapalli
> Sent: Thursday, October 27, 2005 11:22 PM
> To: Monami6 WG
> Subject: Re: [Monami6] Accept
draft-wakikawa-mobileip-multiplecoa-04.txt
> > draft-wakikawa-mobileip-multiplecoa-04.txt has the proposed solution
for

---

From: Vidya Narayanan <[email-masked]>
Date: Thu, 27 Oct 2005 23:37:30 -0500

> maybe I am missing something.

  In general, I think the BID is useful. At any given time, the HoA/CoA pair
is unique - however, when you want to update a particular binding (i.e,
replace CoA1a with CoA1b, say), the BID will help locate the binding.
Without it, you would have to include CoA1a in the BU so that the HA/CN can
identify the correct CoA to replace with CoA1b.
 Regards,
Vidya
_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Vidya Narayanan <[email-masked]>
Date: Thu, 27 Oct 2005 23:43:33 -0500

> reluctant for this document to become a WG doc ?

  Hmmm... Some of the comments can be fixed easily in the draft. But,
depending on how we resolve some other comments, it could change the draft
significantly - for instance, allowing multiple CoA registrations in the
same BU, changes to the returning home behavior, etc. as per my comments
will result in a fair amount of the text to be modified.
 If there is at least some agreement on the issues, it would make sense to
adopt the draft as a WG item. I would be more comfortable with going through
the issues and having one more iteration before making it a WG item though
:)
 Regards,
Vidya
_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 28 Oct 2005 14:38:28 +0900

OK, your comments now seem more "reasonable". More below:

> depending on how we resolve some other comments, it could change the
> draft significantly - for instance, allowing multiple CoA
> registrations in the same BU, changes to the returning home behavior,
> etc. as per my comments will result in a fair amount of the text to be
> modified.

Well, a fair amount of modification is not an issue per se, what would
be a real issue is changes that are incompatible with the current spec.
Your comments seem to indicate that this is not the case, and -speaking
for myself only - I think author could come to the conclusion to
consider such changes as possible.

Of course, we should debate on this list the tradeoffs, e.g multiple
CoAs in the same BU or not: separate BUs has some advantages too.

> adopt the draft as a WG item. I would be more comfortable with going
> through the issues and having one more iteration before making it a WG
> item though:)

I think we can conclude this draft becoming a WG document or not by the
Monami6 meeting. If this is the path chosen by the WG, one more
iteration could be considered if the conclusion is that substantial
changes are needed.

Vancouver is a perfect time to report the issues/concerns that would
have been expressed on the ML.

Thierry.

---

From: Shubhranshu <[email-masked]>
Date: Fri, 28 Oct 2005 19:46:41 +0900

Hi Alex, all

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "Monami6 WG" <[email-masked]>
Sent: Friday, October 28, 2005 1:17 AM
Subject: Re: [Monami6] Accept draft-wakikawa-mobileip-multiplecoa-04.txt asMonami6 WG Document

> written, or about to be written.  Is there?

There is another proposal: draft-jang-mip6-smreg-00.txt 
(http://home.postech.ac.kr/~arche/draft-jang-mip6-smreg-00). However, this
has not been updated since March last year and as such is in bad shape.
 
But the authors do inend to update it, preferably after getting feedbacks 
from this group. IMO, the concept proposed here could be quite useful.

Regards,
Shubhranshu

---

From: Shubhranshu <[email-masked]>
Date: Fri, 28 Oct 2005 19:59:29 +0900

Hi Vidya, all,

----- Original Message ----- 
From: Vidya Narayanan
To: Monami6 WG
Sent: Friday, October 28, 2005 1:43 PM
Subject: Re: [Monami6] Accept draft-wakikawa-mobileip-multiplecoa-04.txt asMonami6 WG Document

<snip>

>Hmmm... Some of the comments can be fixed easily in the draft. But, depending on how we resolve some other comments, it >could
change the draft significantly - for instance, allowing multiple CoA registrations in the same BU, changes to the returning >home
behavior, etc. as per my comments will result in a fair amount of the text to be modified.

Agree.

It would help to allow simultaneous registration of multiple CoAs and
the mechanism should be, at least, flexible enough to accommodate such scenario.
Here, is one scenario where simultaneous registration of multiple CoAs can be
useful/needed:
When the mobile node moves to a new link,  (multiple) CoAs (via old AP/ BS) will
go inactive and new multiple CoAs might become available. It would be preferable
for MN in such situation to register these multiple CoAs simultaneously, using single BU.
IMO, this is quite reasonable since most part of BUs, if sent separately, would be
duplicated except CoA and lifetime.

Note, my intention here is to encourage more discussions by providing
extensions/alternatives and this does not necessarily mean I am against
draft-wakikawa-mobileip-multiplecoa-04.txt.

Regards,
Shubhranshu

>If there is at least some agreement on the issues, it would make sense to adopt the draft as a WG item. I would be more
>comfortable with going through the issues and having one more iteration before making it a WG item though :)

---

From: Shubhranshu <[email-masked]>
Date: Fri, 28 Oct 2005 20:02:49 +0900

Hi Thierry, all,

----- Original Message ----- 
From: "Thierry Ernst" <[email-masked]>
To: "Monami6 WG" <[email-masked]>
Sent: Friday, October 28, 2005 2:38 PM
Subject: Re: [Monami6] Accept draft-wakikawa-mobileip-multiplecoa-04.txt asMonami6 WG Document

<snip>

> consider such changes as possible.

Section 3.1 says  "The mobile node MUST register multiple care-of addresses 
independently."  I would like to know authors opinion on it - if they prefer
to keep it in their future update(s) or not.

Regards,
Shubhranshu

---

From: Koshiro MITSUYA <[email-masked]>
Date: Sun, 30 Oct 2005 19:02:09 +0900

Hi Asanga,

The SHISA/KAME, http://www.mobileip.jp/, supports the draft, although  
we did not try
with the recent version.

regards,
Koshiro

On 2005/10/28, at 13:04, Asanga Udugama wrote:

>>> The WG has been formed with the following deliverable on the
>>>
> charter:
>
>>>
>>> this deliverable, and we are therefore seeking consensus of the
>>>
> Monami6
>
>>> WG. We would like the discussion to happen from now on the mailing
>>>
> list
>
>>>          multiple bindings registered by the mobile node.
>>>
> Assignment of
>
>>>          distinct BID allows a mobile node to register multiple
>>>
> binding
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sun, 30 Oct 2005 19:36:45 +0900

Hi Asanga

At Fri, 28 Oct 2005 06:04:30 +0200,
> this the purpose of having the BID?

yes. 

> so, can I have some info?

Yes. We have been implementing MCoA on BSD. You can get the
implementation from KAME HP (please grep SHISA on the HP) . 

We have codes of MCoA for MIP6 and NEMO, but we confirmed the MCoA for
NEMO, but not yet for MIP6.  Since we have been discussing the
implementation design change of MIP6 right now, it may take some time
to deliver MCoA+MIP code.

thanks
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sun, 30 Oct 2005 19:31:03 +0900

Hi Vijay

At Thu, 27 Oct 2005 14:22:27 -0700,
> in general, I agree with the draft. it should be made

OK

> addresses. we need to figure out a way to make this

Good point. However, which scenario do you need ipsec tunnel?
For RR, HoTI can be sent through the primary CoA.

> use a mobility option. flags are scarce.

This can be easily fixed.

> registration and has processed the BU successfully.

We introduce this extension becase MN need to discover the right HA
when it gets BA with negative status.

> maybe I am missing something.

How do you express interface in MIP6 stack? Do you suggest the use of
name like "en0"?:-)  
BID can be an interface index which most of implementation uses for
interface management.  That's why we use 16bits length for
BID. (interface index is mostly 16bits)

In our system, we bind BID with network interface. We define
well-known BID which express intereface like wifi, ethernet, Ev-Do,
etc. (This is not in the draft though).

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sun, 30 Oct 2005 19:56:48 +0900

Hi Shubhranshu 

This design decision was made to keep the changes to 3775/3963 in
minimum. If WG agreed, it's not burden to support this optimization.

ryuji

At Fri, 28 Oct 2005 20:02:49 +0900,

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sun, 30 Oct 2005 20:03:39 +0900

Hi Shubhranshu

At Fri, 28 Oct 2005 19:59:29 +0900,
> duplicated except CoA and lifetime.

This is valid scenario, although one or two BU may not effect anything. 

If we want simulataneous binding, for example, BID sub-option can be
extended to store alternative IPv6 addreess. If there is no address
included, HA pick an address from the Source address field or the ACoA
sub-opption and register it with BID. On the other hand, if there is
valid address in BID sub-option, it registers the CoA with the BID.

What I want to say here, it's not impossible to support this feature on MCoA.

> draft-wakikawa-mobileip-multiplecoa-04.txt.

:-)

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sun, 30 Oct 2005 19:42:29 +0900

Hi Vidya

At Thu, 27 Oct 2005 23:37:30 -0500,
> identify the correct CoA to replace with CoA1b.

When an interface does not have active signal for a while and MN loses
CoA, no old CoA are available.  There are several cases where no old
CoA are available.  Don't you think it's more straightforward to have
BID instead of using old CoA? 

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sun, 30 Oct 2005 19:50:23 +0900

Hi Vidya

I presented MCoA in MIP6 and NEMO several time. 
We tried to get MCoA standardized for a while and adopted many
comments which was raised from MIP6/NEMO WG.

One of comments was request to simplify the extension. Single BU for
multiple CoAs registration was considered in several time. At the
moment, we did not use single BU, because this may cause some security
vulnerability specially for RR. CoTI/CoT can be used to confirm
rechability for a CoA.
Can you elaborate the part of "returning home behavior"? 

I'm welcome to discuss any issues and ready to update the MCoA.

regards,
ryuji

At Thu, 27 Oct 2005 23:43:33 -0500,

---

From: Vidya Narayanan <[email-masked]>
Date: Sun, 30 Oct 2005 13:04:00 -0500

> BID instead of using old CoA?

I agree. In the case where you don't have a BID, it seems like you
either have to keep the old CoA around as an expired entry or
alternately, the new CoA can be treated as a brand new entry.

Vidya

---

From: "Asanga Udugama" <[email-masked]>
Date: Mon, 31 Oct 2005 10:46:52 +0100

Hello Ryuji, Koshiro,

Thank you for the information. I have gone thru some of the info, I will
continue to do so. The platform that we focus on is Linux, and I wonder
whether I could use some of this code (or techniques) in Linux with
MIPL.

When we implemented the NOMAD (IPv4) draft on SunLabs MIP, I used
NETFILTER & RTNETLINK (with multiple routing table capability) to
distribute traffic. Unfortunately, multiple routing tables are not
available with IPv6 as of this moment. So I was looking around to see
what possibilities I had for implementing this on MIPL.

I am also new to MIPL, and from what I gather, it seems that the new
MIPL (2.0) itself also has implemented parts of RTNETLINK capabilities
for its own use. 

I would appreciate some input regarding this from you all since you have
a lot of experience in this respect.

Thanks in advance.
Kind regards,
Asanga

> From: Ryuji Wakikawa [mailto:[email-masked]]
> Sent: Sunday, October 30, 2005 11:37 AM
> To: Asanga Udugama
> Cc: 'Monami6 WG'

---

From: Nicolas Montavont <[email-masked]>
Date: Mon, 31 Oct 2005 11:15:37 +0100

Hi Ryuji,

...

> etc. (This is not in the draft though).

I am not sure I follow you here. Do you mean that you consider to  
have only one binding HoA/CoA per interface?

Thanks,

Nicolas

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 31 Oct 2005 22:29:12 +0900

Dear Asanga,

> whether I could use some of this code (or techniques) in Linux with

I am also interested in MCoA on Linux as part of the Nautilus project 
(http://www.nautilus6.org). I've started some implementation in NEPL 
(NEMO platform on Linux, based on MIPL2), but not completed yet though.

Studying the MCoA implementation on SHISA can be a good exercise to 
learn more how to implement it, but you may not be able to stick to this 
implementation on Linux as the design between MIPL2 and SHISA is different.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 1 Nov 2005 00:08:04 +0900

Hi NIcolas

> have only one binding HoA/CoA per interface?

Do you consider the case when multiple CoAs are assigned to an  
interface?
Sure. That's possible with the current MCOA draft.

The above example is just example of our system.
In our system, the interface only has one CoA per interface.

ryuji

---

From: Nicolas Montavont <[email-masked]>
Date: Mon, 31 Oct 2005 17:53:45 +0100

Ryuji,

> Sure. That's possible with the current MCOA draft.

Yes, that's what I meant.

> In our system, the interface only has one CoA per interface.

Ok if it's an implementation choice.
However, I think we should allow several CoAs per interface in the spec.

Nicolas

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 01 Nov 2005 07:08:44 +0900

Nicolas

At Mon, 31 Oct 2005 17:53:45 +0100,

OK

> Ok if it's an implementation choice.

yes

> However, I think we should allow several CoAs per interface in the spec.

Again, the current MCoA support this :-)

ryuji

---

From: Romain KUNTZ <[email-masked]>
Date: Tue, 01 Nov 2005 09:02:05 +0900

Hello,

> Again, the current MCoA support this :-)

I have a technical question about that: if the interface is supposed to 
support several CoAs per interface, it means that it can configure 
several CoA from several prefixes advertised on a foreign link. Let say 
that each prefix is advertised by a different Access Router (P1 
advertised by AR1, P2 advettised by AR2). How does the node can make the 
difference between 2 prefixes advertised on the same link and 2 prefixes 
advertised on different link? I mean, if the MN first configure CoA1 
from P1, and then receive a RA with P2, the MN may think it has move in 
another foreign link and replace CoA1 with CoA2.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 31 Oct 2005 17:46:20 -0800

> Good point. However, which scenario do you need ipsec tunnel?

reverse tunneling payload traffic with IPsec protection.

> This can be easily fixed.

ok.

> when it gets BA with negative status.

it just tries the next HA. (?) are you planning to have
something like DHAAD modifications in RFC 3963?

> etc. (This is not in the draft though).

I guess this needs to be evaluated against just sending
a BU with all the current valid CoAs. I wonder if we are
making it more complex than is really necessary.

Vijay