# NAME

ReceivingBA132 - MN receives Binding `Acknowledgement(error` 132)

# TARGET

    Host

# SYNOPSIS

    ReceivingBA132.seq [-tooloption ...] -pkt MN_Common.def

>     -tooloption: v6eval tool option

# TOPOLOGY

                                          |
                                          R       TN
                                          |       |
                                  --------+-------+--------------- LinkZ

                                          |
                                          R2             NUT2
                                          |               |
                                  --------+---------------+------- LinkY

                                          |       |
                                          HA2     R1     NUT1
                                          |       |       |
                                  --------+-------+-------+------- LinkX

                              |           |
                 NUT0        HA1          HA0
                  |           |           |
    Link0 --------+-----------+-----------+-----------------------

> `Link0` | `3ffe:501:ffff:100::/64` | `home link`
> `LinkX` | `3ffe:501:ffff:102::/64` | ``
> `LinkY` | `3ffe:501:ffff:103::/64` | ``
> `LinkZ` | `3ffe:501:ffff:104::/64` | ``
> `HA0(Link0)` | `3ffe:501:ffff:100:200:ff:fe00:a1a1/64` | ``
> `HA1(Link0)` | `3ffe:501:ffff:100:200:ff:fe00:a2a2/64` | ``
> `HA2(LinkX)` | `3ffe:501:ffff:102:200:ff:fe00:a3a3` | ``
> `R1(LinkX)` | `3ffe:501:ffff:102:200:ff:fe00:a4a4` | ``
> `R2(LinkY)` | `3ffe:501:ffff:103:200:ff:fe00:a5a5` | ``
> `TN(LinkZ)` | `3ffe:501:ffff:104:200:ff:fe00:a6a6` | ``

# TEST PROCEDURE

    MN receives Binding Acknowledgement(error 132)

            HA0    NUT0     R1      R2
            |       |       |       |
            | ----> |       |       | RA(H bit)
            |       |       |       |
            |      NUT1     |       |
            |       | <---- |       | RA
            |       |       |       |
            | <---- |       |       | Binding Update (*1)
            | ----> |       |       | Binding Acknowledgement
            |       |       |       |
            |      NUT2     |       |
            |       | <------------ | RA
            |       |       |       |
            | <---- |       |       | Binding Update (*2)
            | ----> |       |       | Binding Acknowledgement (w/ error=132)
            |       |       |       | * 132=home registration not supported
            |       |       |       |
            |       |       |       | NUT SHOULD NOT send BU to HA0 (*3)
            |       |       |       |
            |      NUT1     |       |
            |       | <---- |       | RA
            |       |       |       |
            |       |       |       | NUT SHOULD NOT send BU to HA0 (*4)
            |       |       |       |

# JUDGEMENT

    (*1) PASS: HA0 receives Binding Update

    (*2) PASS: HA0 receives Binding Update

    (*3) PASS: HA0 doesn't receive Binding Update

    (*4) PASS: HA0 doesn't receive Binding Update

# REFERENCE

    draft-ietf-mobileip-ipv6-20.txt

    11.7.3 Receiving Binding Acknowledgements

       Upon receiving a packet carrying a Binding Acknowledgement, a mobile
       node MUST validate the packet according to the following tests:

       o  The packet meets the authentication requirements for Binding
          Acknowledgements, defined in Section 6.1.8 and Section 5.  That
          is, if the Binding Update was sent to the home agent, underlying
          IPsec protection is used.  If the Binding Update was sent to the
          MUST be present and have a valid value.

          be the last option and MUST not have trailing padding.

       o  The Sequence Number field matches the Sequence Number sent by the
          mobile node to this destination address in an outstanding Binding
          Update.

       Any Binding Acknowledgement not satisfying all of these tests MUST be
       silently ignored.

       When a mobile node receives a packet carrying a valid Binding
       Acknowledgement, the mobile node MUST examine the Status field as
       follows:

       o  If the Status field indicates that the Binding Update was accepted
          (the Status field is less than 128), then the mobile node MUST
          update the corresponding entry in its Binding Update List to
          indicate that the Binding Update has been acknowledged; the mobile
          node MUST then stop retransmitting the Binding Update.  In
          addition, if the value specified in the Lifetime field in the
          Binding Acknowledgement is less than the Lifetime value sent in
          the Binding Update being acknowledged, then the mobile node MUST
          subtract the difference between these two Lifetime values from the
          remaining lifetime for the binding as maintained in the
          corresponding Binding Update List entry (with a minimum value for
          the Binding Update List entry lifetime of 0).  That is, if the
          Lifetime value sent in the Binding Update was L_update, the
          Lifetime value received in the Binding Acknowledgement was L_ack,
          and the current remaining lifetime of the Binding Update List
          entry is L_remain, then the new value for the remaining lifetime
          of the Binding Update List entry should be

             max((L_remain - (L_update - L_ack)), 0)

          where max(X, Y) is the maximum of X and Y.  The effect of this
          step is to correctly manage the mobile node's view of the
          binding's remaining lifetime (as maintained in the corresponding
          Binding Update List entry) so that it correctly counts down from
          the Lifetime value given in the Binding Acknowledgement, but with
          the timer countdown beginning at the time that the Binding Update
          was sent.  Mobile nodes SHOULD send a new Binding Update well
          before the expiration of this period in order to extend the
          lifetime.  This helps to avoid disruptions in communications,
          which might otherwise be caused by network delays or clock drift.

       o  If the Status field indicates that the Binding Update was rejected
          (the Status field is greater than or equal to 128), then the
          mobile node SHOULD record in its Binding Update List that future
          Binding Updates SHOULD NOT be sent to this destination.

          Optionally, the mobile node MAY then take steps to correct the
          cause of the error and retransmit the Binding Update (with a new
          Sequence Number value), subject to the rate limiting restriction
          specified in Section 11.8.