[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
- [MEXT] Subject: Multiple CoA draft 10 -- two prop… Christian.Kaas-Petersen
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Giaretta, Gerardo
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Benjamin Lim
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Conny Larsson
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Christian.Kaas-Petersen
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Hesham Soliman
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Giaretta, Gerardo
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Giaretta, Gerardo
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Hesham Soliman
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Benjamin Lim
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Ryuji Wakikawa
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Ryuji Wakikawa
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Giaretta, Gerardo
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Ryuji Wakikawa
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Ryuji Wakikawa
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Giaretta, Gerardo
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Giaretta, Gerardo
- Re: [MEXT] Subject: Multiple CoA draft 10 -- two … Ryuji Wakikawa