[netext] on draft-ietf-netext-pd-pmip-02.txt

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 27 March 2012 14:43 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6033421F8988 for <netext@ietfa.amsl.com>; Tue, 27 Mar 2012 07:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id sSxGyhoeERdr for <netext@ietfa.amsl.com>; Tue, 27 Mar 2012 07:43:23 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4EF6C21F8948 for <netext@ietf.org>; Tue, 27 Mar 2012 07:43:23 -0700 (PDT)
Received: by werb10 with SMTP id b10so5972816wer.31 for <netext@ietf.org>; Tue, 27 Mar 2012 07:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=VATVjZsoxZDbyXszKh3jwxFBtkx/InXw8E9WN6tSRUQ=; b=C+4JvhEoY6u4ER8eN4bBxoTBym+bgpEABGN6y9qqJ78abZ4k/o9P0xiGzAoaYS/dQP MWj+n4uHVaD0NA4xh9u8r2axuijkHK8Z1LfBD3FkiY4Alq6jTaqYTtMTAhdXRQCAWc3R OHmPqcitmKIJ/U6nJBZZ/zc1uPsZTDuhyVanDaALQhJjOizkslOCSWpCf48xqx7VbcDI lJLNWzTE0UrLvRgP5HsrJDgyBhAt5ZqARLY2LdPhNUgiKKN8r6c8DoT/wvLgRF5Sc2fH 17wFGAXcBAD+WHsbzm5dBJqFyMtjshFFFWD8QO3HGFmozCezqud9M2ZhH/acuuSYdTWv YEHA==
Received: by with SMTP id o12mr14709044wei.67.1332859402436; Tue, 27 Mar 2012 07:43:22 -0700 (PDT)
Received: from [] (dhcp-1687.meeting.ietf.org. []) by mx.google.com with ESMTPS id k7sm68304wia.5.2012. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 07:43:21 -0700 (PDT)
Message-ID: <4F71D203.6020401@gmail.com>
Date: Tue, 27 Mar 2012 16:43:15 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: netext@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [netext] on draft-ietf-netext-pd-pmip-02.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Mar 2012 14:43:24 -0000

Is the goal of this draft to achieve network mobility with PMIPv6?  If
so it should say so, rather than "PD for PMIPv6".  Because PD could be
used for PMIPv6 to acquire the HNP not the MNP, and hence just host

It is possible to realize network mobility with PMIPv6 without PD -
divide the allocated HNP into several MNPs and an address.  This draft
does not cover this method.

Why does this draft impose co-locating the LMA with a DHCPv6 Server?  I
think they should be separated.  Pure DHCPv6-PD can work ok when LMA and
DHCPv6 Server are separated.

> 3.   Upon receiving the DHCPv6 SOLICIT message, the MAG sends a PBU
> message including a Mobile Network Prefix (MNP) mobility option as
> defined in Section 4.3 of [RFC3963] to the LMA.

But how does MAG know the MNP at this time?  I believe it doesn't.  I
think there is an issue here.

> The LMA either assigns the MR a new delegated prefix or returns an
> existing one.

I think throughout the draft only DHCPv6 Server assigns a new delegated
prefix, right? (never the LMA, nor the LMA software).

> 4.   On reception of the PBU the LMA returns the assigned prefix in
> the MNP option carried by a Proxy Binding Acknowledgment (PBA) to
> the MAG,

But I thought the MNP is put in a DHCPv6 message, not a PBA, right?

> o  On receiving a packet from the bi-directional tunnel established
> with the MR's LMA, the MAG MUST first decapsulate the packet
> (removing the outer header) and then use the destination address of
> the (inner) packet to forward it on the interface through which the
> destination MNP is reachable.

This would work _only_ if MAG adds a route for the MNP towards the HoA.
  This should be specified.  Otherwise it doesn't work.

> After handover to the new target MAG, a PBU message including the
> assigned mobile network prefix (if available) MUST be sent from the
> new target MAG to the LMA

There is an improvement to achieve this: use the DHCPv6 CONFIRM message.

> o  On receiving a packet from a correspondent node with the
> destination address matching the MR's MNP(s) the LMA MUST forward the
> packet through the bi-directional tunnel set up for the MR.

What do you mean by "matching"?