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

"Pascal Thubert \(pthubert\)" <pthubert@cisco.com> Fri, 10 February 2006 16:57 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7baC-0001fl-6Q; Fri, 10 Feb 2006 11:57:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7baA-0001dB-3x for nemo@megatron.ietf.org; Fri, 10 Feb 2006 11:57:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07542 for <nemo@ietf.org>; Fri, 10 Feb 2006 11:55:34 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7bnB-00004s-Ev for nemo@ietf.org; Fri, 10 Feb 2006 12:10:46 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2006 17:57:07 +0100
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1AGuw5m012480; Fri, 10 Feb 2006 17:57:03 +0100 (MET)
Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 10 Feb 2006 17:57:01 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nemo] RE: draft-ietf-nemo-home-network-models-05
Date: Fri, 10 Feb 2006 17:56:50 +0100
Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01CDCC3B@xmb-ams-337.emea.cisco.com>
Thread-Topic: [nemo] RE: draft-ietf-nemo-home-network-models-05
Thread-Index: AcYuMXEbEjtuoI/PQIKOyrEQX4fGPAAL/CcA
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Alexandru Petrescu <alexandru.petrescu@motorola.com>
X-OriginalArrivalTime: 10 Feb 2006 16:57:01.0416 (UTC) FILETIME=[03086680:01C62E63]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: quoted-printable
Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman <MRW@devicescape.com>, vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org

>>> This above paragraph makes no particular sense at all, since a HA
>>> doing proxy ND for a LFN node which is below MR will intercept
>>> packets from all the neighbours of HA addressed to LFN, even though
>>>  it is the MR who should intercept or receive those packets.
>>>
>>> There can be no "proxy ND" for an LFN on HA's link as long as the
>>> normal ND of same LFN is not happening on the home link.
>>
>> [Pascal] Please read again. The "Nodes on the registered prefixes"
>> means nodes  (eg. LFNs) attached to MRs that are away from home. Thus
>>  MRs can not intercept the packets to the LFN over the Home Link.
>
>For some reason "intercept" was perceived by you as something where MR
>must do proxy ND in order to receive.  I didn't mean so, sorry.  I
meant
>MR should "receive" (or "intercept") packets for LFNs when away from
>home.  This happens by MR receiving packets tunnelled by HA.  The HA
has
>"intercepted" those packets for LFNs by doing proxy ND for MR's Home
>Address exclusively, and not by doing proxy ND for any LFN address.  It
>makes no sense for HA to do proxy ND for LFN address.
>
>Again, HA doing proxy ND for LFNs is something topologically invalid.
>Proxy ND of a host should be done on a link where the real ND for that
>host is topologically valid.

[Pascal] Are we off-sync? This chapter talks about the aggregated mode,
so the whole /48 is topologically correct on the Home Link. That's
section 6 of:
http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod
els-xx.txt

The /48 is what the HA advertises in RA's on the Home Link. All nodes on
the link think that the whole /48 is on that link. So they will have a
connected route to the /48 over the home link, and lookup any node in
the /48 at ND level.

But in fact, (some of) the /48 space is partionned into MNPs affected to
MRs. Thus the problem.
Note: Personally, I do not favor the aggregated model, I prefer the
extended. We discussed that long ago, remember?

>
>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.

>
>Pascal:
>> Thus, on the Home Link, the Home Agent must intercept all the packets
>>  for ALL the Mobile Network Nodes on the registered prefixes - that
>> is for ALL nodes attached to Mobile Routers that are away from Home.
>> This should be a layer 2 operation, rather than layer 3.  The Home
>> agent might, for example,  perform some form of ND proxying for all
>> addresses in all registered Mobile Network Prefixes.  The Home Agent
>> must also protect the MNP space from autoconfiguration by
>> uncontrolled visitors at Neighbor Discovery level.
>
>Is there a known implementation where the HA intercepts all the packets
>for ALL the Mobile Network Nodes by doing proxy ND for their addresses?
>
>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.

Pascal