Re: [nemo] RE: draft-ietf-nemo-home-network-models-05

[Alexandru Petrescu <[e-mail]>]

Pascal Thubert \(pthubert\) wrote:
>>>> 
>>>> Moreover, there are potentially 2^64 LFNs behind an MR with MNP
>>>>  /64.
>>> HA
>>>> has no means to know which of those are active.  So will it
>>>> send 2^64 periodic NAs as part of its proxy ND for LFNs?
>>> 
>>> [Pascal] No, it will answer to NS coming from the Home Link for
>>> any address that matches a registered MNP, and then pass the
>>> packets over the tunnel.
>> 
>> NS is addressed to a multicast group.  In order for HA to receive
>> that NS it should MLD JOIN it first, otherwise it doesn't receive
>> it.  HA would need to send as many MLD JOINs as there are potential
>> LFNs behind MR.  That's large, right?
>> 
> 
> [Pascal] This goes beyond our draft.
> 
> The short answer is that a proxy interface operates in promiscuous
> mode.
> 
> Dave Thaler has documented all this in chapter 4.1.3. "IPv6 ND
> Proxying" of 
> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-04.txt 
> that we reference as [12].

Note that that draft proposes proxy ND with promiscuous mode for a
subnet that is static, always attached to the same AP.  It solves a
problem someone may have in house with a network that stays there.

In the mobility case, if the MR acts as a bridge and the MR and HA do
Thaler promiscuous proxy ND (instead of rfc2461 proxy ND) I doubt the
LFNs will not see the RAs sent either by the home AP or by all visited ARs.

I.e. LFNs will receive RAs straight from the visited network.  Which
will make them auto-configure "CoA"s, loose their communications.  This 
is completely against the NEMO requirement whereby LFNs are protected 
from CoA changes, not run MIP and still keep ongoing sessions.

Mobile Thaler Proxy ND is something one can think about...

>>>> Does anyone plan to write such an implementation?
>>>> 
>>> [Pascal] Dunno. Don't ask me if I like it... But something like
>>> that has to be done if MNs or hosts connect to the home link...
>>> Part of the price to pay to support aggregated mode.
>> 
>> I am not sure the aggregated mode is needed in order to allow the
>> MNNs to connect to MR's home link.  It is sufficient to have an HA
>> on the _MNN_ home link and when MNN connects to MR's home link it
>> would send
> BU
>> to its own HA.
> [Pascal] I'm not sure what you want to say there. Do you mean a MNN
> that is also a MN?

Yes.  I'm not sure what you mean by MNN?  There's only "MH", "MR" and
"MN" that are currently specified, they run Mobile IPv6.  "MNN" is short
for "an MNN can be anything".

I was saying I don't see the need for aggregated mode.  If the need is
to allow nodes on the moving network to connect to the MR's home link
then it is sufficient to put a HA on the link in the moving network
where these nodes reside.  So when such a "MNN" moves from its home link
on the moving network to the MR's home link, it does BU with its HA
(placed in the moving network).

I think it would be fair to mention which home network models are doable 
with RFC3963 and which not.  There are applicability sections.  For 
section 6 "aggregated", it would be very easy to just say "rfc3963 is 
not implementable with the aggregated home model".

Alex