[nemo] PD and frustration

Francis Dupont <Francis.Dupont@enst-bretagne.fr> Wed, 09 November 2005 22:59 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 1EZyun-0002C7-5p; Wed, 09 Nov 2005 17:59:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZyul-0002A7-E1 for nemo@megatron.ietf.org; Wed, 09 Nov 2005 17:59:35 -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 RAA16010 for <nemo@ietf.org>; Wed, 9 Nov 2005 17:59:06 -0500 (EST)
Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZzAo-00053i-Jx for nemo@ietf.org; Wed, 09 Nov 2005 18:16:11 -0500
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jA9Mwba28809 for <nemo@ietf.org>; Wed, 9 Nov 2005 23:58:37 +0100
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jA9MwbP5098982 for <nemo@ietf.org>; Wed, 9 Nov 2005 23:58:37 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200511092258.jA9MwbP5098982@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: nemo@ietf.org
Date: Wed, 09 Nov 2005 23:58:37 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Subject: [nemo] PD and frustration
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

I am not happy at all with the current prefix delegation for NEMO proposals
(draft-ietf-nemo-dhcpv6-pd-00.txt and draft-ietf-nemo-prefix-delegation-00.txt)
I've complained privately but I've been asked to do it in the list.

In the first proposal there are some very strange statements:
 - 3.1.1 assumes the MR-HA tunnel is a part of the home link and
   tries to play with the "intercepted" word. I am sorry but IPv6
   has a clear definition of what is a link and the proposed solution
   is not valid at all.
 - 3.1.3 claims that DHCPv6 relays are not defined for DHCPv6 PD
   when it is not in the RFC nor in recent drafts
   (cf draft-droms-dhc-dhcpv6-agentopt-delegate-00.txt for instance)
But IMHO the DHCPv6 PD service is the right tool, I can see two ways to
support it:
 - put a DHCPv6 relay in the MR itself (i.e., colocated a client and a relay).
   This solves the MR-HA tunnel issue but can be seemed as not natural.
 - put a DHCPv6 relay in the HA and use a dedicated transport on the MR-HA
   tunnel exactly as RS/RA are replaced by MPS/MPA in MIPv6.

The second proposal follows the MPD way but in place to reuse the DHCPv6
service it proposes a fully new and very complex protocol. I don't
understand why and the rationale (quoted below) doesn't convince me.

   Yet, in a deployment where the MNPs are preassigned to the MR, a AAA
   server, interfacing with the HA, and eventually coupled with a
   provisioning system in its back-end, can provide the required service
   for assigning and authorizing the prefixes to the MRs; in such a
   case, the value of implementing a DHCPv6PD server is highly arguable.
   It is more generic to let the HA handle the backend interfaces on
   behalf of the MR and expose a consistent NEMO interface for all
   deployments.

If the issue is the AAA system and DHCPv6 PD service must be interfaced,
for instance to assign only authorized prefix, this issue is not a NEMO
one and is already addresses (fortunately because in the real world
where DHCPv6 PD is already deployed security is not an option).

So I'd like to know what this proposal can do the DHCPv6 PD service can't...

Regards

Francis.Dupont@enst-bretagne.fr