Subject: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt)

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 20 Apr 2009 11:36:38 -0400

Hi all,
#Cc: MEXT chairs and Jari

We completed IESG review and submitted a new version of the  
multiplecoa document (ver13) .
The following changes were implemented in ver13 of the MCoAv6 draft:

1)      Home Registrations
Based on draft v12 there are two way of achieving simultaneous home  
and foreign link registrations.
-          One does NOT associate the home link with a BID and it is  
based on a deregistration at a home link.
-          The other DOES associate the home link with a BID and it is  
based on a registration with a BID option including CoA=HoA and the H=1.

V13 of the draft has been updated so that simultaneous use of home and  
foreign links requires a home registration with BID including CoA=HoA  
and H=1. This simplifies the protocol and unifies all bindings by  
associating all of them with BIDs.

Due to the structure of the document, to implement this change a lot  
of text, mostly under section 5.6, had to be re-written and/or  
rearranged so the diff between v12 and v13 may give the impression of  
major changes. In fact, material was mostly removed, moved, or  
rephrased, and nothing new was added, since all we did is to remove  
one of the options.

2)      CoA field in BID option.
According to draft v12, the CoA may not be included in a BID in some  
cases. The rules for when the CoA is needed or not are however overly  
complex. For example the CoA MAY NOT be included when a BID is  
deregistered but they MUST be included in Bulk Registrations. Draft  
v12 also allows the CoA associated with a BID to  be learned from the  
source address of the packet or the Alt-Coa, which results in  
additional rules about how to handle this.

Draft v13 reduces the complexity of the protocol by simplifying these  
rules as follows:
-          Any BID that is registered for the first time MUST include  
the CoA associated with it.
-          Any BID refreshed, deregistered or otherwise manipulated  
MAY NOT include the CoA
This change was easier to implement. A clear statement defining this  
rules is added at the end of 5.1 and then several references to use of  
Alt-CoA have been cleaned up.

3)      Updated Error Codes
The MCOA BID CONFLICT code is removed since it became unnecessary when  
the ‘O’ flag was introduced. Instead two new error codes  
are added
-          MCOA NON-BID BINDING EXISTS, to indicate that an MN  
attempted to bootstrap MCoA without ‘O’ flag set.  
(Replacement of BID CONFLICT)
-          MCOA UNKNOWN COA, to indicate that the MN send a BID option  
w/o a CoA but the receiver has no record of the BID.

4)    Updated Security Section 9.5.2
1. clarified that the check on the outer IPv6 header source address is  
not required
2. Added text that showed how you can figure out the right CoA for the  
destination address on the outer IP header while using just one IPsec  
SA.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 20 Apr 2009 13:02:14 -0700 (PDT)

Ryuji, the problem I mentioned previously:
http://www.ietf.org/mail-archive/web/mext/current/msg02759.html

stays the same in this version. The draft gives the impression that the same prefix, e.g. 2001:db8:: is required to support multiple interfaces of MN. This is not stated anywhere in the draft but is drawn in Figures 1, 2 and 3.

Regards,

Behcet

________________________________
From: Ryuji Wakikawa <[email-masked]>
To: mext mext <[email-masked]>
Cc: Jari Arkko <[email-masked]>; Julien Laganier <[email-masked]>
Sent: Monday, April 20, 2009 10:36:38 AM
Subject: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt)

Hi all,

We completed IESG review and submitted a new version of the multiplecoa document (ver13) .
The following changes were implemented in ver13 of the MCoAv6 draft:

1)      Home Registrations
Based on draft v12 there are two way of achieving simultaneous home and foreign link registrations.
-          One does NOT associate the home link with a BID and it is based on a deregistration at a home link.
-          The other DOES associate the home link with a BID and it is based on a registration with a BID option including CoA=HoA and the H=1.

V13 of the draft has been updated so that simultaneous use of home and foreign links requires a home registration with BID including CoA=HoA and H=1. This simplifies the protocol and unifies all bindings by associating all of them with BIDs.

Due to the structure of the document, to implement this change a lot of text, mostly under section 5.6, had to be re-written and/or rearranged so the diff between v12 and v13 may give the impression of major changes. In fact, material was mostly removed, moved, or rephrased, and nothing new was added, since all we did is to remove one of the options.

2)      CoA field in BID option.
According to draft v12, the CoA may not be included in a BID in some cases. The rules for when the CoA is needed or not are however overly complex. For example the CoA MAY NOT be included when a BID is deregistered but they MUST be included in Bulk Registrations. Draft v12 also allows the CoA associated with a BID to  be learned from the source address of the packet or the Alt-Coa, which results in additional rules about how to handle this.

Draft v13 reduces the complexity of the protocol by simplifying these rules as follows:
-          Any BID that is registered for the first time MUST include the CoA associated with it.
-          Any BID refreshed, deregistered or otherwise manipulated MAY NOT include the CoA
This change was easier to implement. A clear statement defining this rules is added at the end of 5.1 and then several references to use of Alt-CoA have been cleaned up.

3)      Updated Error Codes
The MCOA BID CONFLICT code is removed since it became unnecessary when the ‘O’ flag was introduced. Instead two new error codes are added
-          MCOA NON-BID BINDING EXISTS, to indicate that an MN attempted to bootstrap MCoA without ‘O’ flag set. (Replacement of BID CONFLICT)
-          MCOA UNKNOWN COA, to indicate that the MN send a BID option w/o a CoA but the receiver has no record of the BID.

4)    Updated Security Section 9.5.2
1.. clarified that the check on the outer IPv6 header source address is not required
2. Added text that showed how you can figure out the right CoA for the destination address on the outer IP header while using just one IPsec SA.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 20 Apr 2009 16:19:11 -0400

Hi Behcet,

Again, why do you say prefix? A home address is shared among multiple  
interfaces.
George have already answered to you.
This MCoA is an extension to Mobile IP. Proxy Mobile IPv6 is not  
supported in this document.

thanks
ryuji

On 2009/04/20, at 16:02, Behcet Sarikaya wrote:

> stays the same in this version. The draft gives the impression that  
> the same prefix, e.g. 2001:db8:: is required to support multiple  
> interfaces of MN. This is not stated anywhere in the draft but is  
> drawn in Figures 1, 2 and 3.
>
> Regards,
>
> Behcet
>
> Cc: Jari Arkko <[email-masked]>; Julien Laganier <[email-masked] 
> >
> -          The other DOES associate the home link with a BID and it  
> is based on a registration with a BID option including CoA=HoA and  
> the H=1.
>
> V13 of the draft has been updated so that simultaneous use of home  
> and foreign links requires a home registration with BID including  
> CoA=HoA and H=1. This simplifies the protocol and unifies all  
> bindings by associating all of them with BIDs.
>
> rearranged so the diff between v12 and v13 may give the impression  
> of major changes. In fact, material was mostly removed, moved, or  
> cases. The rules for when the CoA is needed or not are however  
> overly complex. For example the CoA MAY NOT be included when a BID  
> is deregistered but they MUST be included in Bulk Registrations.  
> Draft v12 also allows the CoA associated with a BID to  be learned  
> from the source address of the packet or the Alt-Coa, which results  
> in additional rules about how to handle this.
>
> rules is added at the end of 5.1 and then several references to use  
> of Alt-CoA have been cleaned up.
>
> 3)      Updated Error Codes
> The MCOA BID CONFLICT code is removed since it became unnecessary  
> when the ‘O’ flag was introduced. Instead two new error  
> codes are added
> -          MCOA UNKNOWN COA, to indicate that the MN send a BID  
> option w/o a CoA but the receiver has no record of the BID.
>
> 1. clarified that the check on the outer IPv6 header source address  
> is not required
> 2. Added text that showed how you can figure out the right CoA for  
> the destination address on the outer IP header while using just one  
> IPsec SA.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 20 Apr 2009 13:38:14 -0700 (PDT)

From: Ryuji Wakikawa <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: mext mext <[email-masked]>; Jari Arkko <[email-masked]>; Julien Laganier <[email-masked]>
Sent: Monday, April 20, 2009 3:19:11 PM
Subject: Re: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt)

[behcet] Is this the mail you are talking about http://www.ietf.org/mail-archive/web/mext/current/msg02758.html?
I don't think he answered it.

This MCoA is an extension to Mobile IP. Proxy Mobile IPv6 is not supported in this document.

[behcet] You mean point-to-point links only in PMIPv6? I don't think so, RFC 4903 is not just for PMIPv6.

thanks
ryuji

On 2009/04/20, at 16:02, Behcet Sarikaya wrote:

> 1. clarified that the check on the outer IPv6 header source address is not required

Hi Behcet,

Again, why do you say prefix? A home address is shared among multiple interfaces.
George have already answered to you.

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 20 Apr 2009 21:54:25 +0100

Bechet,

The prefix you are talking about is the home address. The home address
in MIPv6 sits on a single MIPv6 Interface in the MN which from the
perspective of the host IP stack is unique, fixed, does not move, does
not change...nothing.

All the other (physical) interfaces that come and go have addresses
that become CoAs in the context of MIPv6.

I do not think there is anything strange here.

George

On Mon, Apr 20, 2009 at 9:38 PM, Behcet Sarikaya
<[email-masked]> wrote:
> Cc: mext mext <[email-masked]>; Jari Arkko <[email-masked]>; Julien
> Laganier <[email-masked]>
> [behcet] Is this the mail you are talking
> about http://www.ietf.org/mail-archive/web/mext/current/msg02758.html?
>> http://www..ietf.org/mail-archive/web/mext/current/msg02759.html
>> stays the same in this version. The draft gives the impression that the
>> same prefix, e.g.. 2001:db8:: is required to support multiple interfaces of
>> MN. This is not stated anywhere in the draft but is drawn in Figures 1, 2
>> and 3.
>>
>> Regards,
>>
>> Behcet
>>
>> foreign links requires a home registration with BID including CoA=HoA and
>> H=1. This simplifies the protocol and unifies all bindings by associating
>> all of them with BIDs.
>>
>> Due to the structure of the document, to implement this change a lot of
>> text, mostly under section 5.6, had to be re-written and/or rearranged so
>> the diff between v12 and v13 may give the impression of major changes. In
>> fact, material was mostly removed, moved, or rephrased, and nothing new was
>> added, since all we did is to remove one of the options.
>>
>> complex. For example the CoA MAY NOT be included when a BID is deregistered
>> but they MUST be included in Bulk Registrations. Draft v12 also allows the
>> CoA associated with a BID to  be learned from the source address of the
>> packet or the Alt-Coa, which results in additional rules about how to handle
>> this.
>>
>> This change was easier to implement. A clear statement defining this rules
>> is added at the end of 5.1 and then several references to use of Alt-CoA
>> have been cleaned up.
>>
>> 3)      Updated Error Codes
>> The MCOA BID CONFLICT code is removed since it became unnecessary when the
>> ‘O’ flag was introduced. Instead two new error codes are added
>> -          MCOA NON-BID BINDING EXISTS, to indicate that an MN attempted
>> to bootstrap MCoA without ‘O’ flag set. (Replacement of BID CONFLICT)
>> -          MCOA UNKNOWN COA, to indicate that the MN send a BID option w/o
>> a CoA but the receiver has no record of the BID.
>>
>> destination address on the outer IP header while using just one IPsec SA.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 20 Apr 2009 14:07:00 -0700 (PDT)

George,
  So you are saying that my observation (single prefix is used/must be used on all interfaces of MN) is correct.
  I think that this would create multi-link subnets at the home link and RFC 4903 says we should avoid them by simply assigning different prefixes to each.

Regards,

Behcet

________________________________
From: George Tsirtsis <[email-masked]>
To: Behcet Sarikaya <sarikaya@ieee..org>
Cc: Ryuji Wakikawa <[email-masked]>; Julien Laganier <[email-masked]>; Jari Arkko <[email-masked]>; mext mext <[email-masked]>
Sent: Monday, April 20, 2009 3:54:25 PM
Subject: Re: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt)

Bechet,

George

On Mon, Apr 20, 2009 at 9:38 PM, Behcet Sarikaya
<[email-masked]> wrote:
>> Subject: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13..txt)
>>
>> Hi all,
>> to bootstrap MCoA without ‘O’ flag set.. (Replacement of BID CONFLICT)

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 20 Apr 2009 22:12:08 +0100

sorry Bechet but I think you are missing the point.

As far as the Host IP stack is concerned there is only a SINGLE
Interface (the one presented by MIPv6), the address of which is the
home address or prefix.

Under that virtual MIPv6  Interface, MIPv6 stack hides multiple
physical interfaces. Each of these interfaces has its own separate
prefix.

There is no 'monkey business' of sharing prefixes between interfaces here.

George

On Mon, Apr 20, 2009 at 10:07 PM, Behcet Sarikaya
<[email-masked]> wrote:
>   I think that this would create multi-link subnets at the home link and RFC
> 4903 says we should avoid them by simply assigning different prefixes to
> each.
>
> Regards,
>
> Behcet
>
> Cc: Ryuji Wakikawa <[email-masked]>; Julien Laganier
> <[email-masked]>; Jari Arkko <[email-masked]>;
> mext mext <[email-masked]>
>> From: Ryuji Wakikawa <ryuji.wakikawa@gmail..com>
>> This MCoA is an extension to Mobile IP. Proxy Mobile IPv6 is not supported
>> in this document..
>> [behcet] You mean point-to-point links only in PMIPv6? I don't think so,
>> RFC
>> 4903 is not just for PMIPv6.
>> thanks
>> ryuji
>>
>>> all of them with BIDs..
>>> deregistered
>>> rules
>>> the
>>> w/o
>>> not
>>> required