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

[Sri Gundavelli <[e-mail]>]

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


Sri


On Tue, 2 Dec 2008, [e-mail] wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
>
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext