[MEXT] BU and BA flag overlap between DSMIPv6 (draft-ietf-mext-nemo-v4traversal-06.txt) and Proxy MIPv6 (RFC 5213)
<lorenzo.saino@orange-ftgroup.com> Tue, 02 December 2008 14:29 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 E81ED3A6ABA;
Tue, 2 Dec 2008 06:29:24 -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 D3BBA3A6ABA
for <mext@core3.amsl.com>; Tue, 2 Dec 2008 06:29:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Mlz7536Q8jwO for <mext@core3.amsl.com>;
Tue, 2 Dec 2008 06:29:22 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com
[195.101.245.16])
by core3.amsl.com (Postfix) with ESMTP id 623203A6A48
for <mext@ietf.org>; Tue, 2 Dec 2008 06:29:22 -0800 (PST)
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by
ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 2 Dec 2008 15:29:18 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 2 Dec 2008 15:29:10 +0100
Message-ID: <BAF83494CE653943A97B9F755016A06606A95290@ftrdmel1>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MEXT] BU and BA flag overlap between DSMIPv6
(draft-ietf-mext-nemo-v4traversal-06.txt) and Proxy MIPv6 (RFC
5213)
thread-index: AclUildKI6yFBLDwSeW+fVqEJP3Ggg==
From: <lorenzo.saino@orange-ftgroup.com>
To: <mext@ietf.org>
X-OriginalArrivalTime: 02 Dec 2008 14:29:18.0547 (UTC)
FILETIME=[5C2D6A30:01C9548A]
Subject: [MEXT] BU and BA flag overlap between DSMIPv6
(draft-ietf-mext-nemo-v4traversal-06.txt) and Proxy MIPv6 (RFC 5213)
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
Hello everybody,
I have noticed that in the extension to BU and BA messages proposed in
DSMIPv6 (draft-ietf-mext-nemo-v4traversal-06.txt), the DSMIPv6-specific
flag bits overlap the flag bits proposed in BU and BA message extensions
defined in Proxy MIPv6 (RFC 5213).
More specifically, in the extension to MIPv6 BU message proposed in
DSMIPv6, the flag (F) is located in the same position of the flag (P)
defined in BU extensions proposed in RFC 5213 (Proxy MIPv6). Similarly,
the flag (T) of DSMIPv6 BA message is located in the same position of
flag (P) of Proxy MIPv6 BA message.
To make it easier to compare those messages, I reported the format of BU
and BA messages proposed in Dual Stack MIPv6 and Proxy MIPv6 at the
bottom of this e-mail.
Has this overlapping been designed deliberately?
In my opinion, these overlaps would generate incompatibility issues
between DSMIPv6 and PMIPv6. For this reason, I think they should be
addressed, for instance, by shifting the position of DSMIP-specific
flags (F and T) of 1 bit to the right-hand-side.
Thank you very much for your attention.
If you have already discussed this topic in the mailing list, I
apologize.
Best regards,
Lorenzo Saino
***************************
* BINDING UPDATE MESSAGES *
***************************
PROXY MOBILE IPv6 (RFC 5213)
============================
8.1. Proxy Binding Update Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Binding Update message that is sent by a mobile access gateway to a
local mobility anchor is referred to as the "Proxy Binding Update"
message. A new flag (P) is included in the Binding Update message.
The rest of the Binding Update message format remains the same as
defined in [RFC3775] and with the additional (R) and (M) flags, as
specified in [RFC3963] and [RFC4140], respectively.
Proxy Registration Flag (P)
A new flag (P) is included in the Binding Update message to
indicate to the local mobility anchor that the Binding Update
message is a proxy registration. The flag MUST be set to the
value of 1 for proxy registrations and MUST be set to 0 for direct
registrations sent by a mobile node.
DUAL STACK MOBILE IPv6
======================
4.1.3. The Binding Update Message Extensions
This specification extends the Binding Update message with two new
flags. The flags are shown and described below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|F|T| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Binding Update message
F
When set, this flag indicates a request for forcing UDP
encapsulation regardless of whether a NAT is present on the path
between the mobile node and the home agent.
T
When set, this flag indicates that the mobile node requests the
use of the TLV-format for encapsulating IPv6 in IPv4. The TLV-
format is described later in this document.
************************************
* BINDING ACKNOWLEDGEMENT MESSAGES *
************************************
PROXY MOBILE IPv6 (RFC 5213)
============================
8.2. Proxy Binding Acknowledgement Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Binding Acknowledgement message that is sent by a local mobility
anchor to a mobile access gateway is referred to as the "Proxy
Binding Acknowledgement" message. A new flag (P) is included in the
Binding Acknowledgement message. The rest of the Binding
Acknowledgement message format remains the same as defined in
[RFC3775] and with the additional (R) flag as specified in [RFC3963].
Proxy Registration Flag (P)
A new flag (P) is included in the Binding Acknowledgement message
to indicate that the local mobility anchor that processed the
corresponding Proxy Binding Update message supports proxy
registrations. The flag is set to a value of 1 only if the
corresponding Proxy Binding Update had the Proxy Registration Flag
(P) set to value of 1.
DUAL STACK MOBILE IPv6
======================
4.2.3. Extensions to the Binding Acknowledgement Message
This specification extends the binding acknowledgement message with a
new flag. The new flag is shown and described below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|T| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Binding Acknowledgement message
T
This flag indicates, when set, that the sender of the binding
acknowledgement supports the TLV- tunnel format.
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
- [MEXT] BU and BA flag overlap between DSMIPv6 (dr… lorenzo.saino
- Re: [MEXT] BU and BA flag overlap between DSMIPv6… Sri Gundavelli
- Re: [MEXT] BU and BA flag overlap between DSMIPv6… Hesham Soliman