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

[Hesham Soliman <[e-mail]>]

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

Hesham


On 3/12/08 4:42 AM, "Sri Gundavelli" <[e-mail]> wrote:

> 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


_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext