Subject: [MEXT] BU and BA flag overlap between DSMIPv6 (draft-ietf-mext-nemo-v4traversal-06.txt) and Proxy MIPv6 (RFC 5213)

From: <[email-masked]>
Date: Tue, 2 Dec 2008 15:29:10 +0100

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 2 Dec 2008 09:42:59 -0800 (PST)

I've pointed this out few months back. I thought, its taken care off,
looks like this is not corrected. Hesham ?

Sri

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 03 Dec 2008 08:32:13 +1100

Yes you did and I thought I fixed it. Thanks for the catch, I'll fix this
with the rest of the updates.

Hesham