Subject: [MEXT] Remarkable Misconceptions! Re: [RFC3775 changes] De-registration when returning home

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 21 Mar 2008 11:50:20 +0000

Hi all,

This thread, that became too long too quick, contains a rather
remarkable misconception regarding multihoming. It is rather strange
that I have to explain the concept of layers to a bunch of IETF
old-timers >sigh< but here it is anyway.

The Internet Protocol operates at the network layer.
- IP is usually placed over a link layer (i.e., a link of specific
technology) and thus, it provides basic inter-networking between many
such technology specific links.
- Tunneling and indeed MIPv6 Tunneling is used as an additional layer
(overlay) between the link layer and IP. The purpose of MIPv6
tunneling "layer" is to link multiple IP layer segments that happen to
use different address (i.e., different CoAs).

Now everyone should understand that the concept of *multihoming* can
be applied in every and all layers *separately* and *independently*
from any other layer. For example a node can have multiple physical
layer channels to the same or different link layer technologies;
multiple links to the same or different IP interfaces; several IP
interfaces to the same or different transport layers etc.

MIPv6 as the different layer that it is (!) also has its own
multihoming capability. RFC3775 defines a single CoA per MIPv6 session
(MIPv6 single-homing), while MCoA draft describes how multiple CoAs
can be registered at the same time (MIPv6 Multi-homing). This has
NOTHING to do with IP layer multihoming; it can be combined with IP
layer multi-homing or not but operates separately from it (think
layers!!!).

Lets examine some relevant (non exhaustive) scenarios

Assume an MN that at the MIPv6 tunneling layer is useing basic RFC3775.
- Multihoming at IP Layer: Such an MN can have two IP interface e.g.,
WLAN and 3G. The MN gets two different IP address, for each IP
Interface i.e., the MN is multihomed at the IP layer.
- Singlehoming at MIPv6 Layer: And yet according to RFC37775 the MN
can only register one of the two IP addresses as a CoA to the HA!
i.e., the MN is single-homed at the MIPv6 Layer.

Assume now a different case where the MN at the MIPv6 tunneling layer
is useing basic RFC3775 + MCoA.
- Multihoming at IP Layer: Such an MN can have two IP interface e.g.,
WLAN and 3G. The MN gets two different IP address, for each IP
Interface i.e., the MN is multihomed at the IP layer.
- Multihoming at MIPv6 Layer: In this case according to MCoA, the MN
can register both CoAs at the same time to the HA! i.e., the MN is
multihomed at the MIPv6 Layer

As homework :-) put together other scenarios to prove that
single-homing and multi-homing can operate at different layers
entirely independently from any other layer!

Once the difference between IP layer and MIPv6 layer multihoming is
understood, it should also be possible to understand that a "home
link" and a "foreign link" are all the same thing to IP layer, and the
terms only have significance at the MIPv6 layer. It should also then
be possible to understand that for an IP layer multihomed MN, one of
its links may be a home link and the other a foreign link, or both can
be foreign links, at the MIPv6 layer. The MN should then be able to
use either RFC3775 to enable the use of just one of the two links
(MIPv6 single-homing) or to use MCoA to enable the use of both links
at the same time (MIPv6 multi-homing).

Regards (and sorry for the tutorial style of this e-mail)
George

On Fri, Mar 21, 2008 at 9:50 AM, Alexandru Petrescu
<[email-masked]> wrote:
> Hi Ahmad, at first read I agreed with you but then I thought hmmm... see
>  below.
>
>
>  Ahmad Muhanna wrote:
>  > Hi All,
>  >
>  > I hope that you view this as an attempt to resolve the issue rather than
>  > I am changing my mind. But here the details. I may be repeating myself
>  > here but please bear with me:
>  >
>  > My understanding of "SHOULD" STILL did not change which in this specific
>  > case means the following:
>  >
>  > "The MN MUST send de-registration UNLESS the MN has a valid reason NOT
>  > to send de-registration"
>  >
>  > Initially when we discussed this sometimes back offline, I only gave two
>  > examples why this has to stay "SHOULD":
>  >
>  > A. What happens if the MN as soon as it moves to the home link lost
>  > coverage, MN will not be able to send de-registration.
>  >
>  > B. What happens if the MN as soon as it moves to the home link, the MN
>  > lost power.
>
>  But this two cases are accidental cases.  I think the spec should say
>  what MN is about to do when links are deterministic, the spec shouldn't
>  describe observed behaviours in accidental cases but rather suggest how
>  we'd like MN to act.
>
>  Just some observation,
>
>  Alex
>
>
>
>
>  > I guess these two examples were probably NOT enough for people to
>  > believe in the above definition and my stand for keeping "SHOULD" vs.
>  > changing it to "MUST". However, the scenario which Gerardo and Sri are
>  > referring to makes me believe more strongly that the base RFC3775 need
>  > to keep "SHOULD" and NOT to be replaced with "MUST"
>  >
>  > Here is why?
>  > ============
>  > My understanding of the scenario at hand, is the following (Gerardo's
>  > and Sri's)
>  >
>  > 1. Let us assume that the MN has two interfaces, if1 connected to WLAN
>  > and if2 to something else.
>  > 2. MN is connected to WLAN via if1 and have a BCE with its HA as , CoA1
>  > and HoA1.
>  >
>  > 3. MN for a reason or another starts if2 and finds out that if2 is on
>  > its home link where HoA1 belongs.
>  > 4. However, the MN probably still would like to use if1 for whatever
>  > reason.
>  > 5. The MN does not want to use its HoA1 on if2 YET.
>  >
>  > 6. IMO, at this point, the MN has a valid reason NOT to send
>  > de-registration yet to the HA. Then the rule of "SHOULD" give the MN the
>  > choice of doing so.
>  >
>  > 7. After a certain period of time, the MN decides to use its if2 and
>  > probably HoA1 on if2.
>  > 8. Therefore, the MN has no longer has a valid REASON NOT to send
>  > de-registration to its HA.
>  > 9. In this case the MN and according to the rule of "SHOULD" MUST send a
>  > de-registration message to the HA to stop defending the HoA.
>  >
>  >
>  > NOW: The above scenario constitute example NO. C on my list to support
>  > "SHOULD" rather than "MUST" list above.
>  >
>  > The fact that we now know of this scenario proves one thing, we probably
>  > will have another scenario in the future where Client MIPv6 protocol
>  > will be better served by keeping "SHOULD" rather than "MUST"
>  >
>  > Finally:
>  > ========
>  > I strongly believe that we need to keep the base Client MIP6 protocol,
>  > RFC3775, RFC3775bis, as generic and general and valid to any future
>  > scenario that we are not aware of at this time. Adding a clause and
>  > coupling that with a "MUST" is restricting the base protocol behavior to
>  > a very limited and specific case. On the other hand, whenever, we
>  > identify another scenario like the above, we can always specify the
>  > respected behavior in the respective document where that scenario is
>  > captured without contradicting nor overruling the base Client MIP6
>  > protocol.
>  >
>  > Hope this helps. Cheers to you ALL!
>  >
>  > Regards,
>  > Ahmad
>  >
>  >
>  >> -----Original Message-----
>  >> From: Muhanna, Ahmad (RICH1:2H10)
>  >> Sent: Thursday, March 20, 2008 3:34 PM
>  >> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli';
>  >> 'Giaretta, Gerardo'
>  >> Cc: [email-masked]'
>  >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when
>  >> returning home
>  >>
>  >>
>  >> I just would like to make one thing clear here. So far
>  >> everyone said that from IOT, etc. MN always sends
>  >> de-registration when returns home. IMO, "SHOULD" is working
>  >> as it should:)
>  >>
>  >> However, I do not mind if the original text is changed by
>  >> replacing the respected "SHOULD" by a "MUST" as per Vijay's
>  >> initial proposal.
>  >>
>  >> Regards,
>  >> Ahmad
>  >>
>  >>
>  >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when
>  >> returning
>  >>> home
>  >>>
>  >>>>> Can we improve the text to take this into account?
>  >>>> Agree.
>  >>>>
>  >>>> How about the following?
>  >>>>
>  >>>> OLD:
>  >>>>
>  >>>>     A mobile node detects that it has returned to its home link
>  >>>> through
>  >>>>     the movement detection algorithm in use (Section
>  >>> 11.5.1), when the
>  >>>>     mobile node detects that its home subnet prefix is
>  >>> again on-link.
>  >>>>     The mobile node SHOULD then send a Binding Update to its home
>  >>>> agent,
>  >>>>     to instruct its home agent to no longer intercept or tunnel
>  >>>> packets
>  >>>>     for it.  In this home registration, the mobile node
>  >> MUST set the
>  >>>>     Acknowledge (A) and Home Registration (H) bits, set
>  >> the Lifetime
>  >>>>     field to zero, and set the care-of address for the
>  >>> binding to the
>  >>>>     mobile node's own home address.  The mobile node MUST
>  >>> use its home
>  >>>>     address as the source address in the Binding Updat
>  >>>>
>  >>>> NEW:
>  >>>>
>  >>>>     A mobile node detects that it has returned to its home link
>  >>>> through
>  >>>>     the movement detection algorithm in use (Section
>  >>> 11.5.1), when the
>  >>>>     mobile node detects that its home subnet prefix is
>  >>> again on-link.
>  >>>>     If the mobile node wants the home agent to stop
>  >> intercepting the
>  >>>>     packets meant for its home address, the mobile node
>  >> MUST send a
>  >>>>     de-registration Binding Update to its home agent. In this
>  >>>>     Binding Update, the mobile node MUST set the Acknowledge
>  >>>> (A) and Home
>  >>>>     Registration (H) bits, set the Lifetime field to zero,
>  >>> and set the
>  >>>>     care-of address for the binding to the mobile node's own home
>  >>>>     address.  The mobile node MUST use its home address as
>  >>> the source
>  >>>>     address in the Binding Update.
>  >>>>
>  >>>> Please feel free to modify the text.
>  >>> [Ahmad]
>  >>> Hi Vijay,
>  >>>
>  >>> Let me understand the proposed change here.
>  >>>
>  >>> It seems to me that we just went from "SHOULD" to "MUST"
>  >> and now back
>  >>> to "OPTIONAL".
>  >>>
>  >>> IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD"
>  >>> because my understanding of "SHOULD" is that the MN MUST send
>  >>> de-registration UNLESS there is a condition that makes it
>  >> impossible
>  >>> on the MN to send de-registration, e.g.
>  >>> MN lost coverage, or lost power, etc.
>  >>>
>  >>> The usefulness of SHOULD in base RFC3775 that it can be
>  >> become "MUST"
>  >>> in a specific scenario where that is possibly described in
>  >> a different
>  >>> doc, like the case that Gerardo mentioned. IMO, that "MUST"
>  >> should be
>  >>> captured in the Multi-CoA doc not in RFC3775bis.
>  >>>
>  >>> On the other hand, the latest change defeats the original
>  >> purpose of
>  >>> RFC3775, because RFC3775 mandates on the MN to send
>  >> de-registration,
>  >>> however, the last change, proposed here, makes it based on the MN
>  >>> discretion and that is very dangerous.
>  >>>
>  >>> I disagree with this change and I favor maintaining "SHOULD"
>  >>> in the base document and if "MUST" is needed in a specific
>  >> scenarios
>  >>> let us capture that in the respected document.
>  >>>
>  >>> One final note: Any where we mandate that the MN "MUST" send
>  >>> de-registration, we probably need to have a clause that
>  >> "whenever it
>  >>> is possible for the MN to do so" i.e. if the MN moves to an area
>  >>> without coverage, then the MN wont comply anyway.
>  >>>
>  >>>
>  >>>> Vijay
>  >>>> _______________________________________________
>  >>>> MEXT mailing list
>  >>>> [email-masked]
>  >>>> https://www.ietf.org/mailman/listinfo/mext
>  >>>>
>  >>> _______________________________________________
>  >>> MEXT mailing list
>  >>> [email-masked]
>  >>> https://www.ietf.org/mailman/listinfo/mext
>  >>>
>  > _______________________________________________
>  > MEXT mailing list
>  > [email-masked]
>  > https://www.ietf.org/mailman/listinfo/mext
>  >
>
>
>
> ______________________________________________________________________
>  This email has been scanned by the MessageLabs Email Security System.
>  For more information please visit http://www.messagelabs.com/email
>  ______________________________________________________________________
>  _______________________________________________
>
>
> MEXT mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/mext
>
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 21 Mar 2008 15:22:54 +0100

Hi George,

I find it very interesting... let me ask for some more clarifications.

Would you consider a regular IPv6 host with a single interface card to be multihomed (at the IP layer), given that it has a link-local address and a global address? 

I would relate multihoming at the MIP layer to the number of HoAs, not to the number of (simultaneously registered) CoAs. Looking at this from the perspective of an application running on the MN, it has at its disposal IP addresses assigned to the network interface cards (IP layer multihoming) and the HoAs (MIP multihoming). It doesn't matter if the addresses assigned to the interfaces are registered as CoAs with the HA or not. The registration status of a (potential, or secondary) CoA does not affect the number of addresses the application has at its disposal. 

domagoj

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of George Tsirtsis
> Sent: 21. ozujak 2008 12:50
> To: [email-masked]
> Subject: [MEXT] Remarkable Misconceptions! Re: [RFC3775 
> changes]De-registration when returning home
> 
> Hi all,
> 
> This thread, that became too long too quick, contains a 
> rather remarkable misconception regarding multihoming. It is 
> rather strange that I have to explain the concept of layers 
> to a bunch of IETF old-timers >sigh< but here it is anyway.
> 
> technology) and thus, it provides basic inter-networking 
> between many such technology specific links.
> tunneling "layer" is to link multiple IP layer segments that 
> happen to use different address (i.e., different CoAs).
> 
> Now everyone should understand that the concept of 
> *multihoming* can be applied in every and all layers 
> *separately* and *independently* from any other layer. For 
> example a node can have multiple physical layer channels to 
> the same or different link layer technologies; multiple links 
> to the same or different IP interfaces; several IP interfaces 
> to the same or different transport layers etc.
> 
> (MIPv6 single-homing), while MCoA draft describes how 
> multiple CoAs can be registered at the same time (MIPv6 
> Multi-homing). This has NOTHING to do with IP layer 
> multihoming; it can be combined with IP layer multi-homing or 
> not but operates separately from it (think layers!!!).
> 
> - Multihoming at IP Layer: Such an MN can have two IP 
> interface e.g., WLAN and 3G. The MN gets two different IP 
> address, for each IP Interface i.e., the MN is multihomed at 
> the IP layer.
> - Singlehoming at MIPv6 Layer: And yet according to RFC37775 
> the MN can only register one of the two IP addresses as a CoA 
> to the HA!
> Assume now a different case where the MN at the MIPv6 
> tunneling layer is useing basic RFC3775 + MCoA.
> - Multihoming at IP Layer: Such an MN can have two IP 
> interface e.g., WLAN and 3G. The MN gets two different IP 
> address, for each IP Interface i.e., the MN is multihomed at 
> the IP layer.
> - Multihoming at MIPv6 Layer: In this case according to MCoA, 
> the MN can register both CoAs at the same time to the HA! 
> i.e., the MN is multihomed at the MIPv6 Layer
> 
> single-homing and multi-homing can operate at different 
> layers entirely independently from any other layer!
> 
> Once the difference between IP layer and MIPv6 layer 
> multihoming is understood, it should also be possible to 
> understand that a "home link" and a "foreign link" are all 
> the same thing to IP layer, and the terms only have 
> significance at the MIPv6 layer. It should also then be 
> possible to understand that for an IP layer multihomed MN, 
> one of its links may be a home link and the other a foreign 
> link, or both can be foreign links, at the MIPv6 layer. The 
> MN should then be able to use either RFC3775 to enable the 
> use of just one of the two links
> (MIPv6 single-homing) or to use MCoA to enable the use of 
> both links at the same time (MIPv6 multi-homing).
> 
> Regards (and sorry for the tutorial style of this e-mail) George
> 
> > Hi Ahmad, at first read I agreed with you but then I 
> thought hmmm... 
> > see  below.
> >
> >
> >  Ahmad Muhanna wrote:
> >  > Hi All,
> >  >
> >  > I hope that you view this as an attempt to resolve the 
> issue rather 
> > than  > I am changing my mind. But here the details. I may be 
> > repeating myself  > here but please bear with me:
> >  >
> >  > My understanding of "SHOULD" STILL did not change which in this 
> > specific  > case means the following:
> >  >
> >  > "The MN MUST send de-registration UNLESS the MN has a 
> valid reason 
> > NOT  > to send de-registration"
> >  >
> >  > Initially when we discussed this sometimes back offline, I only 
> > gave two  > examples why this has to stay "SHOULD":
> >  >
> >  > B. What happens if the MN as soon as it moves to the 
> home link, the 
> > MN  > lost power.
> >
> > what MN is about to do when links are deterministic, the spec 
> > shouldn't  describe observed behaviours in accidental cases 
> but rather 
> > suggest how  we'd like MN to act.
> >
> >  Just some observation,
> >
> >  Alex
> >
> >
> >
> >
> >  > changing it to "MUST". However, the scenario which 
> Gerardo and Sri 
> > are  > referring to makes me believe more strongly that the base 
> > RFC3775 need  > to keep "SHOULD" and NOT to be replaced with "MUST"
> >  >
> >  > Here is why?
> >  > ============
> >  > My understanding of the scenario at hand, is the following 
> > (Gerardo's  > and Sri's)  >  > 1. Let us assume that the MN has two 
> > interfaces, if1 connected to WLAN  > and if2 to something else.
> >  > 2. MN is connected to WLAN via if1 and have a BCE with 
> its HA as , 
> > CoA1  > and HoA1.
> >  >
> >  > 3. MN for a reason or another starts if2 and finds out 
> that if2 is 
> > on  > its home link where HoA1 belongs.
> >  > 4. However, the MN probably still would like to use if1 for 
> > whatever  > reason.
> >  > 6. IMO, at this point, the MN has a valid reason NOT to send  > 
> > de-registration yet to the HA. Then the rule of "SHOULD" 
> give the MN 
> > the  > choice of doing so.
> >  >
> >  > 7. After a certain period of time, the MN decides to use its if2 
> > and  > probably HoA1 on if2.
> >  > 9. In this case the MN and according to the rule of 
> "SHOULD" MUST 
> > send a  > de-registration message to the HA to stop 
> defending the HoA.
> >  >
> >  >
> >  > NOW: The above scenario constitute example NO. C on my list to 
> > support  > "SHOULD" rather than "MUST" list above.
> >  >
> >  > The fact that we now know of this scenario proves one thing, we 
> > probably  > will have another scenario in the future where Client 
> > MIPv6 protocol  > will be better served by keeping "SHOULD" 
> rather than "MUST"
> >  >
> >  > Finally:
> >  > ========
> >  > I strongly believe that we need to keep the base Client MIP6 
> > protocol,  > RFC3775, RFC3775bis, as generic and general 
> and valid to 
> > any future  > scenario that we are not aware of at this 
> time. Adding a 
> > clause and  > coupling that with a "MUST" is restricting the base 
> > protocol behavior to  > a very limited and specific case. 
> On the other 
> > hand, whenever, we  > identify another scenario like the 
> above, we can 
> > always specify the  > respected behavior in the respective document 
> > where that scenario is  > captured without contradicting nor 
> > overruling the base Client MIP6  > protocol.
> >  >
> >  >> Sent: Thursday, March 20, 2008 3:34 PM  >> To: Muhanna, Ahmad 
> > (RICH1:2H10); 'Vijay Devarapalli';  >> 'Giaretta, Gerardo'
> >  >> Cc: [email-masked]'
> >  >> Subject: RE: [MEXT] [RFC3775 changes] De-registration when  >> 
> > returning home  >>  >>  >> I just would like to make one 
> thing clear 
> > here. So far  >> everyone said that from IOT, etc. MN 
> always sends  >> 
>  >> as it 
> > should:)  >>  >> However, I do not mind if the original text is 
> > changed by  >> replacing the respected "SHOULD" by a "MUST" as per 
> > Vijay's  >> initial proposal.
> >  >>
> >  >> Regards,
> >  >> Ahmad
> >  >>
> >  >>
> >  >>> Subject: Re: [MEXT] [RFC3775 changes] De-registration when  >> 
> > returning  >>> home  >>>  >>>>> Can we improve the text to 
> take this 
> > into account?
> >  >>>> Agree.
> >  >>>>
> >  >>>> How about the following?
> >  >>>>
> >  >>>> OLD:
> >  >>>>
> > >>> de-registration UNLESS there is a condition that makes it  >> 
> > impossible  >>> on the MN to send de-registration, e.g.
> >  >>> The usefulness of SHOULD in base RFC3775 that it can be  >> 
> > become "MUST"
> >  >>> in a specific scenario where that is possibly 
> described in  >> a 
> > different  >>> doc, like the case that Gerardo mentioned. IMO, that 
> > "MUST"
> >  >> should be
> >  >>> On the other hand, the latest change defeats the original  >> 
> > purpose of  >>> RFC3775, because RFC3775 mandates on the MN 
> to send  
> > >> de-registration,  >>> however, the last change, proposed here, 
> > makes it based on the MN  >>> discretion and that is very dangerous.
> >  >>>
> >  >>> in the base document and if "MUST" is needed in a specific  >> 
> > scenarios  >>> let us capture that in the respected document.
> >  >>>
> >  >>> One final note: Any where we mandate that the MN 
> "MUST" send  >>> 
> > de-registration, we probably need to have a clause that  >> 
> "whenever 
> > it  >>> is possible for the MN to do so" i.e. if the MN moves to an 
> > area  >>> without coverage, then the MN wont comply anyway.
> >  >>>
> >  >>>
> >  >>>> Vijay

---

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 21 Mar 2008 14:34:58 +0000

Domagoj,

Each MIPv6 session at the mobile side presents an IP interface
associated with the HoA (hiding the multiple CoAs underneith). If the
same interface presents additional IP addresses then this is no
different with multiple IP addresses associated with the same Ethernet
Interface.I guess this can also be regarded as multihoming but we are
in danger of getting into a philosophical discussion.

The "tutorial" was to explain why it does not make sense to require
that the MN sends a dereg BU when it connects to its home link.
Instead this is a MIPv6 layer decision that has nothing to do with
whether the MN has connection only to the home link or to one or more
other links at the same time.

I hope we can make some progress understanding this basic point...and
of course then we can also ponder the complexities of multi-homing
applied to different layers at the same time.

Regards
George

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 21 Mar 2008 09:58:40 -0500

George,

I wanted to thank you for the summary on the other email but after
reading your response to Domagoj, I believe my question become more
relevant here. Please see inline.

Regards,
Ahmad

> Sent: Friday, March 21, 2008 9:35 AM
> To: Premec, Domagoj
> Cc: [email-masked]
> Subject: Re: [MEXT] Remarkable Misconceptions! Re: [RFC3775 
> Each MIPv6 session at the mobile side presents an IP 
> interface associated with the HoA (hiding the multiple CoAs 
> underneith). If the same interface presents additional IP 
> addresses then this is no different with multiple IP 
> addresses associated with the same Ethernet Interface.I guess 
> this can also be regarded as multihoming but we are in danger 
> of getting into a philosophical discussion.
> 
> The "tutorial" was to explain why it does not make sense to 
> require that the MN sends a dereg BU when it connects to its 
> home link.
> Instead this is a MIPv6 layer decision that has nothing to do 
> with whether the MN has connection only to the home link or 
> to one or more other links at the same time.

[Ahmad]

I am still not sure where you stand on the original proposed change! 
After all of this tutorial and summary, Do you still see a need to
change "SHOULD" to "MUST"?

Thanks!

> 
> I hope we can make some progress understanding this basic 
> point...and of course then we can also ponder the 
> complexities of multi-homing applied to different layers at 
> the same time.
> 
> Regards
> George
> 
> 
> >  Would you consider a regular IPv6 host with a single 
> interface card to be multihomed (at the IP layer), given that 
> it has a link-local address and a global address?
> >
> >  I would relate multihoming at the MIP layer to the number 
> of HoAs, not to the number of (simultaneously registered) 
> CoAs. Looking at this from the perspective of an application 
> running on the MN, it has at its disposal IP addresses 
> assigned to the network interface cards (IP layer 
> multihoming) and the HoAs (MIP multihoming). It doesn't 
> matter if the addresses assigned to the interfaces are 
> registered as CoAs with the HA or not. The registration 
> status of a (potential, or secondary) CoA does not affect the 
> number of addresses the application has at its disposal.
> >
> >  domagoj
> >
> >
> >
> >
> >  > From: [email-masked] [mailto:[email-masked]] On  > 
> > Behalf Of George Tsirtsis  > Sent: 21. ozujak 2008 12:50  > To: 
> > [email-masked]  > Subject: [MEXT] Remarkable Misconceptions! Re: 
> > [RFC3775  > changes]De-registration when returning home  >  
> > Hi all,  
> > >  > This thread, that became too long too quick, contains 
> a  > rather 
> > remarkable misconception regarding multihoming. It is  > rather 
> > strange that I have to explain the concept of layers  > to 
> a bunch of 
> > IETF old-timers >sigh< but here it is anyway.
> >  >
> >  > - Tunneling and indeed MIPv6 Tunneling is used as an additional 
> > layer  > (overlay) between the link layer and IP. The 
> purpose of MIPv6  
> > > tunneling "layer" is to link multiple IP layer segments that  > 
> >  > Now everyone should understand that the concept of  > 
> *multihoming* 
> > can be applied in every and all layers  > *separately* and 
> > *independently* from any other layer. For  > example a node 
> can have 
> > multiple physical layer channels to  > the same or different link 
> > layer technologies; multiple links  > to the same or different IP 
> > interfaces; several IP interfaces  > to the same or different 
> > transport layers etc.
> >  >
> >  > MIPv6 as the different layer that it is (!) also has its own  > 
> > > (MIPv6 single-homing), while MCoA draft describes how  > multiple 
> > CoAs can be registered at the same time (MIPv6  > 
> Multi-homing). This 
> > has NOTHING to do with IP layer  > multihoming; it can be combined 
> > with IP layer multi-homing or  > not but operates 
> separately from it 
> > (think layers!!!).
> >  >
> >  > Lets examine some relevant (non exhaustive) scenarios  > 
>  > Assume 
> > an MN that at the MIPv6 tunneling layer is useing  > basic RFC3775.
> >  > - Multihoming at IP Layer: Such an MN can have two IP  > 
> interface 
> > e.g., WLAN and 3G. The MN gets two different IP  > address, 
> for each 
> > IP Interface i.e., the MN is multihomed at  > the IP layer.
> >  > - Singlehoming at MIPv6 Layer: And yet according to 
> RFC37775  > the 
> > MN can only register one of the two IP addresses as a CoA  > to the 
> > HA!
> >  > Assume now a different case where the MN at the MIPv6  > 
> tunneling 
> >  > - Multihoming at IP Layer: Such an MN can have two IP  > 
> interface 
> > e.g., WLAN and 3G. The MN gets two different IP  > address, 
> for each 
> > IP Interface i.e., the MN is multihomed at  > the IP layer.
> >  > - Multihoming at MIPv6 Layer: In this case according to MCoA,  > 
> >  > i.e., the MN is multihomed at the MIPv6 Layer  >  > As 
> homework :-) 
> > put together other scenarios to prove that  > single-homing and 
> > multi-homing can operate at different  > layers entirely 
> independently 
> > from any other layer!
> >  >
> >  > Once the difference between IP layer and MIPv6 layer  > 
> multihoming 
> > is understood, it should also be possible to  > understand that a 
> > "home link" and a "foreign link" are all  > the same thing to IP 
> > layer, and the terms only have  > significance at the MIPv6 
> layer. It 
> > should also then be  > possible to understand that for an IP layer 
> > multihomed MN,  > one of its links may be a home link and 
> the other a 
> > foreign  > link, or both can be foreign links, at the MIPv6 
> layer. The  
> > > MN should then be able to use either RFC3775 to enable 
> the  > use of 
> > just one of the two links  > (MIPv6 single-homing) or to 
> use MCoA to 
> > enable the use of  > both links at the same time (MIPv6 
> multi-homing).
> >  >
> >  > Regards (and sorry for the tutorial style of this 
> e-mail) George  >  
> > > On Fri, Mar 21, 2008 at 9:50 AM, Alexandru Petrescu  > 
> > thought 
> > hmmm...
> >  > >  > I hope that you view this as an attempt to resolve the  > 
> > issue rather  > > than  > I am changing my mind. But here 
> the details. 
> > I may be  > > repeating myself  > here but please bear with me:
> >  > >  >
> >  > >  > My understanding of "SHOULD" STILL did not change which in 
> > this  > > specific  > case means the following:
> >  > >  >
> >  > >  > "The MN MUST send de-registration UNLESS the MN has 
> a  > valid 
> > reason  > > NOT  > to send de-registration"
> >  > >  >
> >  > >  > Initially when we discussed this sometimes back offline, I 
> > only  > > gave two  > examples why this has to stay "SHOULD":
> >  > >  >
> >  > >  > A. What happens if the MN as soon as it moves to 
> the  > home 
> > link lost  > > > coverage, MN will not be able to send 
> > de-registration.
> >  > >  >
> >  > >  > B. What happens if the MN as soon as it moves to 
> the  > home 
> > link, the  > > MN  > lost power.
> >  > >
> >  > >  But this two cases are accidental cases.  I think the spec  > 
> > should say  > > what MN is about to do when links are 
> deterministic, 
> > the spec  > > shouldn't  describe observed behaviours in accidental 
> > cases  > but rather  > > suggest how  we'd like MN to act.
> >  > >
> >  > >  Just some observation,
> >  > >
> >  > >  Alex
> >  > >
> >  > >
> >  > >
> >  > >
> >  > >  > I guess these two examples were probably NOT enough for  > 
> > people to  > > > believe in the above definition and my stand for 
> > keeping  > "SHOULD" vs.
> > Gerardo 
> > and Sri  > > are  > referring to makes me believe more 
> strongly that 
> > the base  > > RFC3775 need  > to keep "SHOULD" and NOT to 
> be replaced 
> > with "MUST"
> >  > >  >
> >  > >  > Here is why?
> >  > >  > ============
> >  > >  > My understanding of the scenario at hand, is the 
> following  > 
> >  > >  > 2. MN is connected to WLAN via if1 and have a BCE 
> with  > its 
> > HA as ,  > > CoA1  > and HoA1.
> >  > >  >
> >  > >  > 3. MN for a reason or another starts if2 and finds 
> out  > that 
> > if2 is  > > on  > its home link where HoA1 belongs.
> >  > >  > 4. However, the MN probably still would like to use 
> if1 for  > 
> > > whatever  > reason.
> >  > >  > 7. After a certain period of time, the MN decides 
> to use its 
> > if2  > > and  > probably HoA1 on if2.
> >  > >  > 8. Therefore, the MN has no longer has a valid 
> REASON  > NOT 
> > to send  > > > de-registration to its HA.
> >  > >  > 9. In this case the MN and according to the rule of  > 
> > "SHOULD" MUST  > > send a  > de-registration message to the 
> HA to stop  
> > > defending the HoA.
> >  > >  >
> >  > >  >
> >  > >  > The fact that we now know of this scenario proves 
> one thing, 
> > we  > > probably  > will have another scenario in the future where 
> > Client  > > MIPv6 protocol  > will be better served by 
> keeping "SHOULD"
> >  > rather than "MUST"
> >  > >  >
> >  > >  > Finally:
> >  > >  > ========
> > > > protocol,  > RFC3775, RFC3775bis, as generic and general  > and 
> > valid to  > > any future  > scenario that we are not aware 
> of at this  
> > > time. Adding a  > > clause and  > coupling that with a "MUST" is 
> > restricting the base  > > protocol behavior to  > a very 
> limited and 
> > specific case.
> >  > On the other
> >  > > hand, whenever, we  > identify another scenario like the  > 
> > above, we can  > > always specify the  > respected behavior in the 
> > respective document  > > where that scenario is  > captured without 
> > contradicting nor  > > overruling the base Client MIP6  > protocol.
> >  > >  >
> >  > >  >> From: Muhanna, Ahmad (RICH1:2H10)  > >  >> Sent: Thursday, 
> > March 20, 2008 3:34 PM  >> To: Muhanna, Ahmad  > > (RICH1:2H10); 
> > 'Vijay Devarapalli';  >> 'Giaretta, Gerardo'
> >  > >  >> Cc: [email-masked]'
> > >>  > > returning home  >>  >>  >> I just would like to make one  > 
> > thing clear  > > here. So far  >> everyone said that from 
> IOT, etc. MN  
> > > always sends  >>  > > de-registration when returns home. IMO, 
> > "SHOULD" is working  >  >> as it  > > should:)  >>  >> 
> However, I do 
> > not mind if the original text is  > > changed by  >> replacing the 
> > respected "SHOULD" by a "MUST" as per  > > Vijay's  >> initial 
> > proposal.
> >  > >  >>
> >  > >  >> Regards,
> >  > >  >> Ahmad
> >  > >  >>
> >  > >  >>
> > >>  > > returning  >>> home  >>>  >>>>> Can we improve the 
> text to  > 
> > take this  > > into account?
> >  > >  >>>> Agree.
> >  > >  >>>>
> >  > >  >>>> How about the following?
> >  > >  >>>>
> >  > >  >>>> OLD:
> >  > >  >>>>
> >  > >  >>> IMO, the best for RFC3775 and RFC3775bis is to  > 
> maintain 
> > "SHOULD"
> >  > >  >>> because my understanding of "SHOULD" is that the MN MUST 
> > send  > > >>> de-registration UNLESS there is a condition 
> that makes 
> > it  >>  > > impossible  >>> on the MN to send de-registration, e.g.
> >  > >  >>> in a specific scenario where that is possibly  > 
> described 
> > in  >> a  > > different  >>> doc, like the case that Gerardo 
> > mentioned. IMO, that  > > "MUST"
> >  > >  >> should be
> > >>  > > purpose of  >>> RFC3775, because RFC3775 mandates 
> on the MN  > 
> > to send  > > >> de-registration,  >>> however, the last change, 
> > proposed here,  > > makes it based on the MN  >>> 
> discretion and that 
> > is very dangerous.
> >  > >  >>>
> > send  >>>  > > de-registration, we probably need to have a 
> clause that  
> > >>  > "whenever  > > it  >>> is possible for the MN to do 
> so" i.e. if 
> > the MN moves to an  > > area  >>> without coverage, then 
> the MN wont 
> > comply anyway.
> >  > >  >>>
> >  > >  >>>
> >  > >  >>>> Vijay
> >  > >  This email has been scanned by the MessageLabs Email  
> > Security 
> > System.
> >  > >  For more information please visit  > 
> > http://www.messagelabs.com/email  > >  > 
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Mar 2008 11:29:21 -0700

Hi George,

The way I see it, we are trying to clarify the Mobile IPv6 stack
behavior on a mobile node in 3775bis. We are not trying to describe
how a mobile node multi-homed at the IP layer is supposed to behave.

Now coming to multi-homing at the IP layer and the MIPv6 layer,
there are two models.

- The Mobile IPv6 home address is assigned to a virtual interface
on the mobile node. There might be multiple interfaces at the IP
layer. When any of these interfaces attach to the home link, the
home address is moved from the MIPv6 virtual interface to the
interface with which it attached to the home link. Once this
happens, your concept of MIPv6 tunneling layer (the overlay who
talk about below) disappears. The MIPv6 virtual interface is now
the same as the interface with which the mobile node attaches to
the home link. You could also think of it as the overlay layer
disappears when the mobile node attaches to the home link.

- The Mobile IPv6 home address is assigned to the virtual
interface all the time. There is always a MIPv6 tunneling layer
that is independent of the IP layer. In this case, the mobile node
actually never comes home. It will have separate IP addresses on
each of its IP interface, which it could use as the care-of
address(es). This is the true overlay model that you describe below.

Multiple home address and multiple CoAs are not relevant to this
discussion.

Now coming to the issue at hand, are we describing the MIPv6 stack
behavior on the mobile node? If yes, are you saying that the MIPv6
stack on the mobile node totally ignores the interface that is now
attached to the home link? Is it that interface outside the purview
of MIPv6? If not, the MIPv6 stack needs to deal with it when it
attaches to the home link. It can choose to disable it (or not
configure any address) till it figures out what to do the interface.
It can continue getting the packets tunneled to the other interface
which is still attached to the visited link. Or it can decide to
make use of the interface, and move the home address to that
interface. This would require the mobile node to delete the binding
at the home agent so that it can send/receive packets from the
home link.

Finally, we come to the basic case - a mobile node with just one
interface (single-homed at the IP layer). Here the mobile node
should obviously send a de-registration BU as soon as it attaches
to the home link with the one interface it has. The mobile node must 
also make sure that the home address is usable on the IP interface.
Otherwise it cannot send/receive packets from the home link.

Vijay