[MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments

<Christian.Kaas-Petersen@tieto.com> Thu, 11 December 2008 14:08 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: monami6-archive@megatron.ietf.org
Delivered-To: ietfarch-monami6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902493A6A6F; Thu, 11 Dec 2008 06:08:27 -0800 (PST)
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 C2D0A3A69E2 for <mext@core3.amsl.com>; Thu, 11 Dec 2008 06:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.526
X-Spam-Level:
X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 kBjBv7vxVHD6 for <mext@core3.amsl.com>; Thu, 11 Dec 2008 06:08:24 -0800 (PST)
Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id 6CB0A3A6A2B for <mext@ietf.org>; Thu, 11 Dec 2008 06:08:24 -0800 (PST)
X-AuditID: c10cb581-00000f2c000004d8-c4-49411ece2cd4
Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 15:08:14 +0100
Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Dec 2008 15:08:16 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 11 Dec 2008 15:08:16 +0100
Message-ID: <D3CFEF84287B46408A7F0405EE7C545701969E24@corvette.eu.tieto.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Subject: Multiple CoA draft 10 -- two proposals and some comments
Thread-Index: AclbmelbVEZqE1eBQTKM/5HFe6iu1g==
From: <Christian.Kaas-Petersen@tieto.com>
To: <mext@ietf.org>
X-OriginalArrivalTime: 11 Dec 2008 14:08:16.0873 (UTC) FILETIME=[E9E0FD90:01C95B99]
X-Brightmail-Tracker: AAAAAA==
Subject: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some 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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Assume a mobile node with home address HoA has two interfaces,
both attached to foreign links.  After exchange of binding update
and binding acknowledgement, the home agent's binding cache (at
least the snip of it related to HoA) will look like this

    HoA, BID= 7, CoA1, other parameters like period of validity...
    HoA, BID=10, CoA2, other parameters ...

The draft uses HoA=2001:db8::EUI.

Draft 10, section 5.1 states, that a BID value must be unique for a
home address and care-of address pair.  This is satisfied above, but
it means, that the mobile station is not allowed to change the
second entry such that it also uses CoA1 as care-of address.

Proposal:  I think it has merit to be able to allow more than
one BID value per pair of home address and care-of address.  Consider
flow bindings (defined in draft-ietf-mext-flow-binding) where
a flow may refer to a BID, and thus there is a simple way to move
flows between interfaces: only updating the binding cache.

Draft 10, section 4.2 (and other places) defines the H flag, which when
set means the mobile node wants to use both its home link and one or
more of its foreign links.  The H flag is really an instruction to the
home agent, that in addition to all the bidings currently defined
is shall have an extra binding where packets shall not be tunneled.  

Proposal:  The mobile node should be able to define a binding saying

    HoA BID=0 HoA

This is a kind of default binding to be used when any of the other HoA-
bindings cannot be used.  I think the H flag is an indirect way of
saying there is an extra binding, whereas the binding above is direct.
It also avoids continuously setting the H flag when both home link
and foreign links are active.


Other comments

 o Figure 1: In general I think it simpler for human readers to have
   the elements of the primary key to a database given first,
   therefore I suggest

       binding [2001:db8::EUI  BID1  care-of address1]

   to be used allover.

 o Figure 4: looks as if position 6 is followed by position 17.

 o Section 4.2, O flag.  The O flag is carried in an Binding
   Identification mobility option, but really it a kind of global
   value to be understood by the receiver as "clean all HoA entries".
   If it really is too much to introduce a new mobility option,
   isn't it enough to set the O flag in the first Binding
   Identification mobility option?

 o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet 2.
   If the care-of address is omitted, the care-of address is to be
   taken from the source address of the IPv6 header.
   When the binding update arrives at the home agent, the
   IPv6 header's source address is exactly the care-of
   address used by the mobile node, but when the home agent is 
   actually able to understand the contents of the binding update,
   then the IPv6 headers source address has been swapped with the
   address found in the Destination Option extension header,
   and thus the care-of address is now found in the Destination
   Option extension header.

 o Section 5.6.2, bullet 2.  The term link-local address is used, but I
   think this should be changed to be like in all the other places,
   using link-layer address.

 o Section 6.2, bullet 7, sub-bullet 1: I think the condition should
read
   "If one of the 'O' flags is set, then all of the 'O' flags must be
   set, else [MCOA MALFORMED] is returned."  But as suggested above, 
   I don't think there is reason to enforce an all-or-none 'O' flags.

 o Section 8.2, para 2.  The text says, that the IPv4 Address
   Acknowledgement mobility option is included only if the mobile node
   requested a home address.  When I read
draft-ietf-mext-nemo-v4traversal,
   section 4.2.1, the IPv4 Address Acknowledgement mobility option
   is included always, indicating the home agent created a binding cache
   entry for the IPv4 home address.

Christian 


_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext