Subject: [Monami6] H flag and no NDP

From: Suresh Krishnan <[email-masked]>
Date: Wed, 25 Jul 2007 15:33:01 -0400

Hi Folks,
   I believe that the problem Ryuji was addressing is real and it needs 
to be addressed. I do not agree though that a protocol extension is 
necessary to do this.
   I have an alternate mechanism to propose. Let's say an MN has 2 
interfaces (both on a foreign link). The HA has two bindings
1) HoA to CoA1
2) HoA to CoA2

Now let's say one of the interfaces returns home. The MN will deregister 
on this interface. When the HA removes this binding, it MUST check for 
other bindings for this HoA and flag them with a "No PROXY NDP" flag.

I think this will solve the problem without any protocol modifications 
and only behavior modifications on the HA.

Cheers
Suresh

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

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 26 Jul 2007 04:38:05 +0800

Hello, Surresh,

I don't know what qualifies as a "protcol extension" ... but there is
currently no "No-ND-Proxy" flag in any standards track document, IIRC.

/rgds
/cwng

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Wed, 25 Jul 2007 15:52:55 -0500

Hi Suresh,

On 2007/07/25, at 14:33, Suresh Krishnan wrote:

> Hi Folks,
>   I believe that the problem Ryuji was addressing is real and it  
> needs to be addressed. I do not agree though that a protocol  
> extension is necessary to do this.
> Now let's say one of the interfaces returns home. The MN will  
> deregister on this interface. When the HA removes this binding, it  
> MUST check for other bindings for this HoA and flag them with a "No  
> PROXY NDP" flag.
>
> I think this will solve the problem without any protocol  
> modifications and only behavior modifications on the HA.

neat!  We don't need H flag in BID-sub-option.
I personally think this approach is better than H-flag.
We don't need extra modification to MCoA for this specific scenario.
Thanks Suresh.

As I said in the meeting, the solution of either H-flag or Suresh's  
idea does solve the  problem of simultaneous location in home/foreign,
but this gives you certain limitation of how to deploy HA on the home  
link. (ex. HA must be the solo router on the link, etc).
I refer draft-wakikawa-mip6-no-ndp-01.txt, because it summarizes the  
operational limitation of HA when proxy ND is removed.
No protocol specification is introduced in the document.
http://tools.ietf.org/id/draft-wakikawa-mip6-no-ndp-01.txt
I should list up the required operational tips for HA in the MCoA  
instead of referring to the document so that we can avoid delay.

regards,
ryuji

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Wed, 25 Jul 2007 15:54:07 -0500

Hi Chan-Wah,

> currently no "No-ND-Proxy" flag in any standards track document, IIRC.

This flag can be implemented anyway. This flag is used internally on HA.
We don't need the interoperability as long as HA stop proxy ND.

regards,
ryuji

>> needs
>> deregister
>> modifications

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Jul 2007 16:05:11 -0500

Suresh Krishnan wrote:
> Hi Folks, I believe that the problem Ryuji was addressing is real and
>  it needs to be addressed. I do not agree though that a protocol 
> extension is necessary to do this. I have an alternate mechanism to 
> propose. Let's say an MN has 2 interfaces (both on a foreign link). 
> The HA has two bindings 1) HoA to CoA1 2) HoA to CoA2
> 

There is a situation that needs to be avoided.

I think we don't want the HA to not proxy ND for a HoA when one
interface is at home, because if it does so then it will not be able to
intercept packets sent by a host on the home link towards that HoA and
to deliver it to the CoA of the interface that didn't return home.

I mean, if the HA wants to keep a binding entry for a CoA that is still
remote then it wants to intercept packets for it.  Even if the HA is the
single and default router on the home link, that HA will not intercept
packets addressed to a HoA on the home link if it doesn't do proxy ND.

Otherwise, I think you think that there is actually no home link, and
thus the whole point of coming back home is invalid too, together with
proxy ND not being needed at all.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Wed, 25 Jul 2007 16:10:46 -0500

Hi Alex,

On 2007/07/25, at 16:05, Alexandru Petrescu wrote:

>> extension is necessary to do this. I have an alternate mechanism  
>> to propose. Let's say an MN has 2 interfaces (both on a foreign  
>> link). The HA has two bindings 1) HoA to CoA1 2) HoA to CoA2
>> MUST check for other bindings for this HoA and flag them with a  
>> "No PROXY NDP" flag.
>

Please check the http://tools.ietf.org/id/draft-wakikawa-mip6-no- 
ndp-01.txt
If on-link flag is unset in RA, all the packets are routed to the HA.
HA can decide whether the packet should routed directly to the HoA or  
tunneled to MN.

ryuji

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 26 Jul 2007 05:15:17 +0800

Hello,

Ah, I see.  Now I understand Suresh's proposal (BTW, sorry for the extra
'r' previously).

That's is dangerous IMHO.  You are changing the way a deregister BU
works.  More analysis needs to done on how this will impact the
operations in the following cases:

(1) One of MN's interface returns home and deregister that binding.

(2) One of MN's interface loses connection and deregister that binding.

(3) One of MN's interface returns home and MN shuts down the foreign
interface simultaneously, and deregistering both bindings.

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Jul 2007 16:17:50 -0500

RYUJI WAKIKAWA wrote:
>>> Hi Folks, I believe that the problem Ryuji was addressing is real
>>> and it needs to be addressed. I do not agree though that a
>>> protocol extension is necessary to do this. I have an alternate
>>> mechanism to propose. Let's say an MN has 2 interfaces (both on a
>>> foreign link). The HA has two bindings 1) HoA to CoA1 2) HoA to
>>> CoA2 Now let's say one of the interfaces returns home. The MN
>>> will deregister on this interface. When the HA removes this
>>> binding, it MUST check for other bindings for this HoA and flag
>>> them with a "No PROXY NDP" flag.
>> 
>> interface is at home, because if it does so then it will not be
>> able to intercept packets sent by a host on the home link towards
>> that HoA and to deliver it to the CoA of the interface that didn't
>> return home.
> 
> Please check the

Ok, sorry.

>  HA can decide whether the packet should routed directly to the HoA
> or tunneled to MN.

Why would HA (the single and default router on the home link) not set
the on-link flag for prefix in RA?  I think the only reason why it would
not set the onlink flag for a certain prefix is because there is no
actual physical link, something like ptp links straight to HA.  But not
sure.

I don't understand why you assume that there is a real home link where
the MN returns home but at the same time there is no real home link for
proxy ND.

Alex

---

From: Keigo Aso <[email-masked]>
Date: Thu, 26 Jul 2007 07:39:50 +0900

Hi Suresh,

I can not understand why this work.
How does HA know MN's intention, whether MN wants to utilize both interface
or only the interface attached to home link or only the interface attached to
foreign link at one time ?

Regards,
Keigo

On Wed, 25 Jul 2007 15:33:01 -0400

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 26 Jul 2007 06:23:56 -0500

Hi all,

Since when RFC3775 mention de-registration, it associate that with two
cases:
1. returning home, and since returning home means that MN binding is
gone with all CoAs.
2. de-registering Primary Care of Address, or as RFC3775 captures it,
the MN no longer has any CoA in the visited network.

Then de-registration based on RFC3775 means de-registration for the MN
binding with all CoA.

"
10.3.2.  Primary Care-of Address De-Registration

   A binding may need to be de-registered when the mobile node returns
   home or when the mobile node knows that it will not have any care-of
   addresses in the visited network.
"

However, since we are addressing the extension of MIPv6 to support
multiple binding with clear BID, I guess both solutions should work:

1. A clear indication by setting the "H" bit in the BID option:
This requires a new definition of the HA behavior. Which is already
done.

2. The second approach by Suresh should work too:
In this case, the new HA behavior is not according to RFC3775 but to be
also defined as Suresh mentioned. The de-registration carries a specific
BID option and the HA should only de-register that one.

In the case that the MN would like to de-register all BIDs, then the
process as per RFC3775 should suffice.

Regards,
Ahmad

> -----Original Message-----
> From: Keigo Aso [mailto:[email-masked]] 
> Sent: Wednesday, July 25, 2007 5:40 PM
> To: Suresh Krishnan
> Cc: Monami6 WG
> Subject: Re: [Monami6] H flag and no NDP
> 
> Hi Suresh,
> 
> How does HA know MN's intention, whether MN wants to utilize 
> both interface or only the interface attached to home link or 
> only the interface attached to foreign link at one time ?
> 
> Regards,
> Keigo
> 
> > needs to be addressed. I do not agree though that a 
> protocol extension 
> > is necessary to do this.
> > MUST check for other bindings for this HoA and flag them 
> with a "No PROXY NDP" flag.
> >

---

From: Keigo Aso <[email-masked]>
Date: Thu, 26 Jul 2007 23:00:45 +0900

Hello Ahmad,

Thank you for your clarification.
As you said, when MN uses BID, I also think de-registration of a specific BC
should be available. I could understand the approach by Suresh for this process.
In this case, after HA de-registers that BC, the forwarding destination
would be only another BC entry based on RFC3775, so after de-registration, 
no new HA behavior. 
And then H-flag is used to allow HA to know MN's request to
create the home binding as well as another BC. This flag is valid for 
Registration, Deregistration and bulk registration as described 
in the current draft. I think this may be just Registration because 
it creates the home binding.

Regards,
Keigo

On Thu, 26 Jul 2007 06:23:56 -0500

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 31 Jul 2007 14:42:40 +0900

Hi Ahmad,

Thanks for clarification.

Home binding is used for internal purpose on HA. Home binding is  
nothing to do with interoperability.
I believe this is the reason not to use H flag here.
However, as keigo said, H flag is used for MN to ask HA to keep using  
both interfaces attached to home and foreign.
If H flag is not set, HA just removes all the registered bindings.

The question is, "Is it any scenario whether MN changes its behavior  
at the home link dynamically?".
Or, is it sufficient if HA is configurable?

As long as user/operator can change the HA configuration (turn on/off  
simultaneous location support),
we don't need H-flag and follow the Suresh's proposal.

ryuji

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 31 Jul 2007 14:43:51 +0900

Hi Alex,

> actual physical link, something like ptp links straight to HA.  But  

If there is CN on the home link, HA cannot capture the packet.
CN tries to solve the ND for MN on the home link, because the prefix  
of MN and CN are on-link.

ryuji

---

From: Benjamin Koh Tien-Ming <[email-masked]>
Date: Tue, 31 Jul 2007 14:02:09 +0800

Hi all!

> The question is, "Is it any scenario whether MN changes its behavior at
> the home link dynamically?".
[BK]
In a sense the H-flag is used precisely to allow MN to change HA
configuration, albeit in a dynamic manner. MN's behaviour may be static
for a single session but this may/likely change depending on the
application/CN it is communicating with.

Also, borrowing the thread from Chan-Wah, following the proposal from
Suresh seems hasty if the following implications have not been thought out.
(1) One of MN's interface returns home and deregister that binding.
(2) One of MN's interface loses connection and deregister that binding.
(3) One of MN's interface returns home and MN shuts down the foreign
interface simultaneously, and deregistering both bindings.

>>> with a "No PROXY NDP" flag.
[BK]
Will this be the default behaviour? What if MN chooses to power down an
interface due to power constraints and sends a deregistration BU? If
such a solution is to be adopted we will likely need some other
parameter to inform HA of whether MN intends to continue using the
"supposedly" home-attached interface.

My thinking is that the H-flag is a clear, simple and easy to implement
mechanism that does not make any out-of-band assumptions on HA and/or MN
behaviours and functionalities.

Thoughts?

Regards,
Ben

RYUJI WAKIKAWA wrote:
> Home binding is used for internal purpose on HA. Home binding is nothing
> to do with interoperability.
> The question is, "Is it any scenario whether MN changes its behavior at
> the home link dynamically?".

-- 

/<<<<<<<<<<<<<<<<<<<<++>>>>>>>>>>>>>>>>>>>>\
| Benjamin Koh Tien-Ming                   |
| R & D Engineer                           |
| Panasonic Singapore Laboratories Pte Ltd |
| Tel: (65)6550 5481 Fax: (65)6550 5459    |
| E-mail: [email-masked]  |
\>>>>>>>>>>>>>>>>>>>>--<<<<<<<<<<<<<<<<<<<</

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Jul 2007 14:30:00 +0200

RYUJI WAKIKAWA wrote:
>>> Hi Alex, On 2007/07/25, at 16:05, Alexandru Petrescu wrote:
>>>> Suresh Krishnan wrote:
>>>>> Hi Folks, I believe that the problem Ryuji was addressing is
>>>>> real and it needs to be addressed. I do not agree though that
>>>>> a protocol extension is necessary to do this. I have an
>>>>> alternate mechanism to propose. Let's say an MN has 2
>>>>> 1) HoA to CoA1 2) HoA to CoA2 Now let's say one of the
>>>>> interfaces returns home. The MN will deregister on this
>>>>> interface. When the HA removes this binding, it MUST check
>>>>> for other bindings for this HoA and flag them with a "No
>>>>> PROXY NDP" flag.
>>>> There is a situation that needs to be avoided. I think we don't
>>>> want the HA to not proxy ND for a HoA when one interface is at
>>>> home, because if it does so then it will not be able to
>>>> intercept packets sent by a host on the home link towards that
>>>> HoA and to deliver it to the CoA of the interface that didn't 
>>>> return home.
>>> Please check the 
>>> If on-link flag is unset in RA, all the packets are routed to the
>>> HA. HA can decide whether the packet should routed directly to
>>> the HoA or tunneled to MN.
>> 
>> Why would HA (the single and default router on the home link) not
>> set the on-link flag for prefix in RA?  I think the only reason why
>> it would not set the onlink flag for a certain prefix is because
>> there is no actual physical link, something like ptp links straight
>> to HA.  But not sure.
> 
> If there is CN on the home link, HA cannot capture the packet. CN
> tries to solve the ND for MN on the home link, because the prefix of
>  MN and CN are on-link.

Right... CN on home link can't resolve the MN's MAC address if the MN is
not at home and the HA does not do proxy ND for it.  If the HA does
proxy ND then the CN on home link _can_ solve the MAC address.

Not sure I understand why you want to remove the proxy ND.  The reason I 
could think of is when there is no home link at all, but at that point 
we don't talk returning home...

Alex

> 
> ryuji
> 
>> 
>> I don't understand why you assume that there is a real home link
>> where the MN returns home but at the same time there is no real
>> home link for proxy ND.
>> 
>> Alex
>> 
>> 
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit
>> http://www.messagelabs.com/email 
>> _______________________________________________ Monami6 mailing
>> list [email-masked] 
> _______________________________________________ Monami6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
>