[MEXT] draft-xia-mext-hioptv4-01 and draft-ietf-mip6-hiopt-17 comments

Tomasz Mrugalski <tomasz.mrugalski@gmail.com> Thu, 17 March 2011 21:56 UTC

Return-Path: <tomasz.mrugalski@gmail.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720893A6B2C for <mext@core3.amsl.com>; Thu, 17 Mar 2011 14:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irDDB2rxQ1eg for <mext@core3.amsl.com>; Thu, 17 Mar 2011 14:56:26 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 5896D3A6B24 for <mext@ietf.org>; Thu, 17 Mar 2011 14:56:26 -0700 (PDT)
Received: by wwa36 with SMTP id 36so2786130wwa.13 for <mext@ietf.org>; Thu, 17 Mar 2011 14:57:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=czXiDfCsNY7wW+itM4VUN6r+bw6dQscKve7lz5Uinoo=; b=wZ1sKP3FHL9IwF6cC5Z6LYMjk6cWnolx5PrIfqB1RUzpqh2oCuUG5rgmINMmtT9aTL wiOXStHiDe0wDMDF1TCX4pHOgklszRR1mf++vqxJfJJMTnvAmmEQF6DKJq/b3ct+gQ66 8bxo3RdZRjqRsO+PeCwVHV7HvuxUfEfa2Z4IU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=v2NExxN7MCVtLZFsAaazysI05q08lu7hEbW1tUJzXz716MAmROBp+X04VrTuefDEcx 9UzIG36Uc/IS1FwBIU7JZWaML4onWXlawZE02l8+fPuprlVDxhi9WDoMwlOFxHfvn9TE t1SFbhg7oyHp5S3Rl+oOd7XafF3UWCgnU/8k0=
Received: by 10.216.143.17 with SMTP id k17mr1381814wej.74.1300399074076; Thu, 17 Mar 2011 14:57:54 -0700 (PDT)
Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl [109.107.11.157]) by mx.google.com with ESMTPS id o6sm2103649wbo.3.2011.03.17.14.57.53 (version=SSLv3 cipher=OTHER); Thu, 17 Mar 2011 14:57:53 -0700 (PDT)
Message-ID: <4D8283DF.7030702@gmail.com>
Date: Thu, 17 Mar 2011 22:57:51 +0100
From: Tomasz Mrugalski <tomasz.mrugalski@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: MEXT WG <mext@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Behcet Sarikaya <behcetsarikaya@yahoo.com>
Subject: [MEXT] draft-xia-mext-hioptv4-01 and draft-ietf-mip6-hiopt-17 comments
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2011 21:56:27 -0000

Dear MEXT WG,
Behcet asked me to review draft-xia-mext-hioptv4-01.txt. It refers to
draft-ietf-mip6-hiopt-17.txt, so I'd like to briefly comment on both of
them.

Disclaimer: I'm not involved in MEXT activity (nor do I intend to). I'm
quite familiar with DHCPv6 and to some extent DHCPv4 protocols, so my
comments are related to those aspects.

draft-ietf-mip6-hiopt-17:
MIP6 Relay Agent Option defined in Section 3.2 of
draft-ietf-mip6-hiopt-17 is specific to one option only. On the other
hand Ted's RSOO proposal is generic and can be applied to any options.
This make RSOO better approach. I strongly suggest to modify Section 3.2
of draft-ietf-mip6-hiopt-17 to reference RSOO draft, rather than define
its own dedicated option.

draft-xia-mext-hioptv4-01:
In Section 1 you enumerate all IPv4-IPv6 permutations, without any
justification why they are actually needed. What's the use case there?
My understanding is that there is Dual Stack mobile node. Is it supposed
to do DHCPv4 only? Why? If client visits network that is IPv4 only, how
is it supposed to do MIPv6?

If you have dual stack mobile node, it should run both DHCPv4 and DHCPv6
clients, each configuring its own protocol family.

I think Ted's major objection was Section 4.2, where DSMIPv6 Relay
Agent Option is defined. Why do you need this option for? What options
is it supposed to carry? Are you expecting it to convey DHCPv6 options,
as defined in mip6-hiopt-17? That would be wrong on many levels. You
would encapsulate DHCPv6 suboptions into DHCPv4 options. DHCPv4 clients
typically don't have parsing capabilities of DHCPv6 option formats.

At current form, this draft is unclear at best. Who is including
OPTION_DSMIP6_RELAY option? Relay?

My generic recommendation is that authors should should start with:
- explaining why you need this instead of using DHCPv4 for IPv4
  configuration and DHCPv6 for IPv6 configuration.
- redesigning those option to not requiring conveying DHCPv6 options in
  DHCPv4.
- explain your use case and the rationale behind it.


References:
RSOO draft:
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-relay-supplied-options/

Please keep me on cc: as I'm not subscribed to mext mailing list.

-- 
Tomek