Subject: [MEXT] was Re: [Monami6] returning home issue in MCoA

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 21 Nov 2007 13:40:53 +0000

To respond to Nikolas initial question on this issue I think that
simultaneous home-foreign connectivity issues should be discussed and
resolved as part of the MCoA draft. In any case Ryuji already listed a
number of options, not all of which are too complex. It seems to me that ND
proxying or not, by who, and when is the only remaining question :-)

I have to say that the H flag and the description of this in MCoA-v4 is not
yet clear enough so there is certainly more work to be done here.

I am also going to send additional comments on the MCoA draft separately.

Thanks
George
P.S.: I moved this to MEXT list now, and below is the last e-mail I received
on this issue on monami6 list....not sure if I missed anything in between.

-----Original Message-----
From: Keigo Aso [mailto:[email-masked]]
Sent: Monday, November 19, 2007 1:52 AM
To: Monami6 WG
Subject: Re: [Monami6] returning home issue in MCoA

Hi Ryuji,

On Sun, 18 Nov 2007 11:36:49 +0900

RYUJI WAKIKAWA <[email-masked]> wrote:

> Hi Vijay,

> On 2007/11/18, at 7:05, Vijay Devarapalli wrote:

> > RYUJI WAKIKAWA wrote:

> >>> But now I puzzled why the HA would be turning of proxy ND? I think

> >>> the HA should still continue proxying the home address of the mobile

> >>> node and intercept the packets.

> >> Then, HA and MN will meet the address duplication.

> >> MN tries to defend its HoA on the home link and HA also tries to do

> >> the same by Proxy ND.

> > No. The MN does not attempt to defend its address when it knows

> > that it has another binding from a visited link. It knows that

> > the HA will be proxying its home address. Basically the HA would

> > defined whether to send the traffic directly to the home address

> > on the link or tunnel to the CoA that the MN has registered at

> > the HA. The HA would make the decision based on the type of

> > packet/flow..

> >>> The HA then decides how to forward the packet. If the packet is

> >>> meant the MN interface which is not attached to the home link, the

> >>> packet should be tunneled to the mobile node on the visited link. If

> >>> the packet is meant for the MN interface which is attached to the

> >>> home link, the HA delivers it directly. The tricky part would be to

> >>> create a neighbor cache entry for the mobile node so that the HA

> >>> can deliver the packet on-link. The HA would need to know the L2

> >>> address of the interface with which the mobile node is attached to

> >>> the home link.

> >> Do you suggest to modify ND parts for this?

> > Is there a need to modify neighbor discovery? As long as the

> > HA has the layer 2 address that corresponds to the interface

> > with which the mobile node is attached to the home link, it can

> > construct a neighbor cache entry or for example construct the

> > ether header.

> It sounds similar to the MN's operation of sending dereg-BU from home

> link.

> - How can HA learn the MN's L2 address.

> - when MN communicates with CN on the home link, the packets are

> always routed through the HA

> - Regardless of binding status, HA MUST defend the HoA at the home link.

>     While MN is back to home with multiple bindings, HA will intercept

> all the packets and decides how to deliver the packets to MN. However,

> if MN stop using the interfaces attached to foreign link, HA will no

> longer defend the HoA. It means MN MUST start defending own HoA at the

> home link. I think this is a bit tricky. HA should do proxy NDP for

> HoA regardless of binding status of MN.

> - From the implementation experience of returning home, it is very

> hard to implement this;-p

I think it is better to assume HA is a router on the home link as described
in

your draft no-ndp-00 in order to avoid to introduce needless complexity
here.

When MN connects to both home and foreign link, if HA can see all packets
for

the HoA of the MN by IP routing, it would not need to do proxy ND for

intercepting packets. MN can do ND for own HoA here.

While, when MN's both interfaces connects to foreign link, HA should do
proxy ND

for defending the HoA of the MN, according to RFC3775.

And, I agree with Vijay's comments.

Even when MN connects to both home and foreign link, HA can do proxy ND for
the

network which its egress interface connects to for intercepting packets for
the

HoA of the MN.

In this case, I think it is better for HA to stop proxy ND for the home
link.

If so, MN can start ND for defeinding own HoA and HA can know MN's L2
address.

There is no change on ProxyND in home link defined by RFC3775.

Regards,

Keigo

> ryuji

> > Vijay

> >> ryuji

> >>> Vijay

> >>>> If you answer YES to the question above,

> >>>> Should MCoA document support this feature?

> >>>> [ ] YES

> >>>> [ ] NO (not in MCoA, but in a separate document)

> >>>> The deadline for this consensus call  is October the 8th 2007.

> >>>> Thank you,

> >>>> Monami6 chairs

> >>>> _______________________________________________

> >>>> Monami6 mailing list

> >>>> [email-masked]

> >>>> https://www1.ietf.org/mailman/listinfo/monami6

> >>> _______________________________________________

> >>> Monami6 mailing list

> >>> [email-masked]

> >>> https://www1.ietf.org/mailman/listinfo/monami6

> >> _______________________________________________

> >> Monami6 mailing list

> >> [email-masked]

> >> https://www1.ietf.org/mailman/listinfo/monami6

> > _______________________________________________

> > Monami6 mailing list

> > [email-masked]

> > https://www1.ietf.org/mailman/listinfo/monami6

> _______________________________________________

> Monami6 mailing list

> [email-masked]

> https://www1.ietf.org/mailman/listinfo/monami6

_______________________________________________

Monami6 mailing list

[email-masked]

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 21 Nov 2007 15:14:23 -0800

Hi Ryuji and George,

George Tsirtsis wrote:
> number of options, not all of which are too complex. It seems to me that 
> ND proxying or not, by who, and when is the only remaining question :-)

Right, we need to figure this out. :)

I think we should go with the home agent intercepting the packets
all the time in this scenario. This means the home agent would
proxy the mobile node's home address. Once the home agent receives
the packet, it decides whether to deliver the packets locally on
if1 or tunnel to CoA on if2.

If we let the mobile node respond to neighbor solicitations, then
I don't see how packets meant for if2 will ever get tunneled to
the CoA. The mobile node will always receive the packets on-link
on if1.

Vijay

>  
> I have to say that the H flag and the description of this in MCoA-v4 is 
> not yet clear enough so there is certainly more work to be done here.
> 
> P.S.: I moved this to MEXT list now, and below is the last e-mail I 
> received on this issue on monami6 list....not sure if I missed anything 
> in between.
> 
>  
> 
> From: Keigo Aso [mailto:[email-masked] 
> <mailto:[email-masked]>]
> RYUJI WAKIKAWA <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>  
> 
>  > Hi Vijay,
> 
>  >
> 
> I think it is better to assume HA is a router on the home link as 
> described in
> 
> When MN connects to both home and foreign link, if HA can see all 
> packets for
> 
> Even when MN connects to both home and foreign link, HA can do proxy ND 
> for the
> 
> network which its egress interface connects to for intercepting packets 
> for the
> 
> HoA of the MN.
> 
>  > >>>> [email-masked] <mailto:[email-masked]>
> 
>  > >>> [email-masked] <mailto:[email-masked]>
> 
>  > >> [email-masked] <mailto:[email-masked]>
> 
>  > > [email-masked] <mailto:[email-masked]>
> 
>  > [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> 
> ------------------------------------------------------------------------
>

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 22 Nov 2007 09:15:10 +0000

Yes I agree that allowing the HA to continue intercepting the packets
is necessary if the HA is supposed to direct at least some of them
away from the home link.

The question then is how packets are sent by the HA to the mobile over
the home link. If the home link is a p2p link there should be no
issue, but on shared links how is the l2 address of the mobile
discovered by the HA? One way would be the mobile to add it in the BU
it sends to the HA to indicate such a partial deregistration but it
sounds like too much of a layer violation. Another could be for the HA
to do a reverse lookup one the address on the link to discover the mac
address of the mobile.

George

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 22 Nov 2007 11:29:03 -0800 (PST)

Hi George,

> to do a reverse lookup one the address on the link to discover the mac

Its not just about the home agent learning the L2 address of
the mobile node. Assuming HA intercepts the packets and it
has the ability to route some of those intercepted packets
to the home interface of the mobile node and some over the
tunnel and to a different interface of the mobile node.
But, for the other direction, how can the mobile node use the
home interface to send any packets. What is neigbor view of
that home address with respect to HoA ownership and the L2
association ? IMO, the solution is not simple and requires
some fundamental changes that are beyond the monami scope
and can always be addressed outside this doc.

Also, if the home link is a p2p link, this is not an issue.
HA is always in the path and L2 address has little purpose
there. But, p2p home link assumption is a big assumption.

Sri

---

From: Keigo Aso <[email-masked]>
Date: Fri, 23 Nov 2007 08:28:23 +0900

Hello George,

> to do a reverse lookup one the address on the link to discover the mac
I agree with what you said above. P2P case has no issue.
Actually p2p home link is considerable as the actual deployment and in that case,
the connection between HA and MN would be wireless. So, the returning home
scenario is necessity for HA and MN for switching path, which should be solved
by MCoA, I also think so.

'H' flag in current MCoA is simple way for this p2p link scenario. MN sends BU
with 'H' flag and then HA stops ProxyND for the ingress interface connecting to
the home link. After that, MN can start NDP for own HoA. If HA needs to do
ProxyND for intercepting packets for MN's HoA, it can do it for the egress
interface. Of course if HA can intercept packets by IP routing, no need to do it.

While, for the shared link case, actually we can use a option such as Link-Layer
Address (LLA) Option by RFC4068(FMIP) for the way of BU to include l2 address
which you proposed. I think this is possible way.

Regards,
Keigo