[Mip4] AD review of draft-ietf-mip4-nemo-v4-base
Jari Arkko <jari.arkko@piuha.net> Mon, 21 January 2008 15:40 UTC
Return-path: <mip4-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGyku-0001vU-TE; Mon, 21 Jan 2008 10:40:12 -0500
Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1JGykt-0001qk-DI for mip4-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 10:40:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGykt-0001qc-3J for mip4@ietf.org; Mon, 21 Jan 2008 10:40:11 -0500
Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGyks-0001GX-H7 for mip4@ietf.org; Mon, 21 Jan 2008 10:40:11 -0500
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D03F2198CF9; Mon, 21 Jan 2008 17:40:09 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 9744E198CAF; Mon, 21 Jan 2008 17:40:09 +0200 (EET)
Message-ID: <4794BCDC.2050508@piuha.net>
Date: Mon, 21 Jan 2008 17:40:12 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071022)
MIME-Version: 1.0
To: draft-ietf-mip4-nemo-v4-base@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: Mobile IPv4 Mailing List <mip4@ietf.org>
Subject: [Mip4] AD review of draft-ietf-mip4-nemo-v4-base
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
Errors-To: mip4-bounces@ietf.org
I have reviewed this specification. It is generally in good shape. There are a few observations below; I think you should address them but they were not grave enough for me to block the progress of the document. If you can, it would be helpful if you could revise the document in the next few days, as I will be starting IETF Last Call. Regarding recent discussion on the list, please do not introduce new changes to the draft, except if there's a clear bug. Route optimization, etc. should be out of scope. Technical: > Optionally, all requested Mobile > Networks could be acknowledged using only one Mobile Network > Acknowledgement extension with "Prefix Length" and "Prefix" fields > set to zero. I think this is unnecessary complexity. Suggest deleting this possibility. > 5. Propagate Mobile Network Prefix routes via routing protocol This seems unnecessary in some typical cases, such as when the home agent already advertises a shorter prefix that contains this new prefix. > The > solution described here does not place any restriction on the number > of levels for nested mobility. But note that this might introduce > significant overhead on the data packets as each level of nesting > introduces another tunnel header encapsulation. In fairness, it should be noted that this specification is incapable of detecting loops in such nesting configurations. As a result, I think we should warn the reader about these configurations with stronger language than there is currently. > If a dynamic routing protocol is used between the Mobile Router and > the Home Agent to propagate the mobile network information into the > home network, the routing updates SHOULD be protected with IPsec ESP > confidentiality between the Mobile Router and Home Agent, to prevent > information about home network topology from being visible to > eavesdroppers. > > A routing protocol message protected with ESP, and sent through the > Mobile Router - Home Agent bidirectional tunnel, SHOULD NOT contain > the Mobile IPv4 Mobile-Home Authentication Extension, since ESP > provides enough security. Are you specifying how to protect the routing protocol in question (not your job!) or merely requiring the tunnel packets carrying these routing exchanges are ESP protected? If the former, revise. If the latter, OK. But even in that case, is the Mobile IPv4 Mobile-Home Authentication Extension really used on tunnel packets? > The policy of future assignments to this number space should be > following Expert Review. > I believe "Standards Action or IESG Approval" would be more appropriate, for reasons of ensuring interoperability. Editorial: > Although Mobile IPv4 stated that Mobile Network can be supported by > the Mobile Router and Home Agent using static configuration or > running a routing protocol, there is no solution I suppose you meant "Although the original Mobile IPv4 specifications claimed that ..." Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/
- [Mip4] AD review of draft-ietf-mip4-nemo-v4-base Jari Arkko
- [Mip4] Re: AD review of draft-ietf-mip4-nemo-v4-b… Alexandru Petrescu
- [Mip4] Re: AD review of draft-ietf-mip4-nemo-v4-b… Jari Arkko