NAME

MN-3-4-1-2-001 - Starting the return routability procedure (when receiving BRR)


TARGET

Host


TOPOLOGY

                    
                                  |
                                  R       CN0
                                  |        |
                     -----+-------+--------+---------------- LinkZ
                          |
                          R2                      NUTY
                          |                         |
                     -----+-------+-----------------+------- LinkY
                                  |
                                  R1              NUTX
                                  |                 |
                     -----+-------+-----------------+------- LinkX
                          |
                         HA0             Node0    NUT0
                          |               |         |
    ----------------------+---------------+---------+------- 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:a0a0  
Node0(Link0) 3ffe:501:ffff:100:200:ff:fe00:a3a3  
R1(LinkX) 3ffe:501:ffff:102:200:ff:fe00:a4a4  
R2(LinkY) 3ffe:501:ffff:103:200:ff:fe00:a6a6  
CN0(LinkZ) 3ffe:501:ffff:104:200:ff:fe00:a8a8  


INITIALIZATION

 1. Selection Option
    - Route Optimization support : YES
    - Receiving Binding Refresh Request : Return Routability
 2. Position of Mobile Node
       HA0     NUT0     R1      R2      CN0
        |       |       |       |        |
        | ----> |       |       |        | 1.Router Advertisement
        |       |       |       |        |
        |      NUTX     |       |        |
        |       |       |       |        |
        |       | <---- |       |        | 2.Router Advertisement
        |       |       |       |        |
        | <---- |       |       |        | 3.Neighbor Solicitations
        |       |       |       |        | 4.(no reply:3 seconds)
        |       |       |       |        |
        | <---- |       |       |        | 5.Binding Update
        | ----> |       |       |        | 6.Binding Acknowledgement
        |       |       |       |        |
                    
        1. Send Router Advertisement. (HA0 -> HA0_allnode_multi)
        2. Send Router Advertisement. (R1 -> R1_allnode_multi)
        3. Receive Neighbor Solicitations. (NUT0 -> HA0)
        4. (no reply)
            # Wait during a maximum of 3 seconds(RFC2461).
        5. Receive Binding Update. (NUTX -> HA0)
        6. Send Binding Acknowledgement. (HA0 -> NUTX)


TEST PROCEDURE

                    
       HA0     NUTX     R1      R2      CN0
        |       |       |       |        |
        | ====> | <--------------------- | 1.ICMP Echo Request
        |       |       |       |        |
        | <==== | ---------------------> | 2.Home Test Init
        |       | ---------------------> | 3.Care-of Test Init
        |       | <--------------------- | 4.Care-of Test
        | ====> | <--------------------- | 5.Home Test
        |       |       |       |        |
        | <==== | ---------------------> | 6.ICMP Echo Reply
        |       | ---------------------> | 7.Binding Update
        |       | ---------------------> | 8.ICMP Echo Reply
        |       |       |       |        |
        | ====> | <--------------------- | 9.Binding Refresh Request
        |       |       |       |        |
        | <==== | ---------------------> | 10.Home Test Init (*1)
        |       | ---------------------> | 11.Care-of Test Init (*1)
        |       | <--------------------- | 12.Care-of Test
        | ====> | <--------------------- | 13.Home Test
        |       |       |       |        |
        |       | ---------------------> | 14.Binding Update (*2)
        |       |       |       |        |
                    
                    
        1. Send ICMP Echo Request. (out: HA0 -> NUTX, in: CN0 -> NUT0)
        2. Receive Home Test Init. (out: NUTX -> HA0, in: NUT0 -> CN0)
        3. Receive Care-of Test Init. (NUTX -> CN0)
        4. Send Care-of Test. (CN0 -> NUTX)
        5. Send Home Test. (out: HA0 -> NUTX, in: CN0 -> NUT0)
        6. Receive reverse tunneled ICMP Echo Reply or [8]. (out: NUTX -> HA0, in: NUT0 -> CN0)
        7. Receive Binding Update to CN0. (NUTX -> CN0)
        8. [6] or Receive ICMP Echo Reply. (NUTX -> CN0)
        9. Send Binding Refresh Request. (out: HA0 -> NUTX, in: CN0 -> NUT0)
       10. Receive Home Test Init. (out: NUTX -> HA0, in: NUT0 -> CN0)
       11. Receive Care-of Test Init. (NUTX -> CN0)
       12. Send Care-of Test. (CN0 -> NUTX)
       13. Send Home Test. (out: HA0 -> NUTX, in: CN0 -> NUT0)
       14. Receive Binding Update to CN0. (NUTX -> CN0)
                    
        Packet Format is:
          9.Binding Refresh Request
          10.Home Test Init
          11.Care-of Test Init
          14.Binding Update to CN0
                    


JUDGEMENT

 (*1) PASS: CN0 receive the Home Test Init and the Care-of Test Init.
 (*2) PASS: CN0 receives Binding Update.
      Then, check whether this packet fills all of the following.
        - Check whether the Lifetime fills all of the following.
           - The Lifetime is set less than MAX_RR_BINDING_LIFE(420seconds).
           - The Lifetime is set less than the remaining lifetime
             of the home registration.
           - The Lifetime is set less than the remaining lifetime
             of care-of address.


REFERENCE

                    
(draft-ietf-mobileip-ipv6-24.txt)
                    
11.7.4 Receiving Binding Refresh Requests
                    
   When a mobile node receives a packet containing a Binding Refresh
   Request message, the mobile node has a Binding Update List entry for
   the source of the Binding Refresh Request, and the mobile node wants
   to retain its binding cache entry at the correspondent node, then the
   mobile node should start a return routability procedure.  If the
   mobile node wants to have its binding cache entry removed it can
   either ignore the Binding Refresh Request and wait for the binding to
   time out, or it can at any time delete its binding from a
   correspondent node with an explicit binding update with zero lifetime
   and the care-of address set to the home address.  If the mobile node
   does not know if it needs the binding cache entry, it can make the
   decision in an implementation dependent manner, such as based on
   available resources.
                    
   Note that the mobile node should be careful to not respond to Binding
   Refresh Requests for addresses not in the Binding Update List to
   avoid being subjected to a denial of service attack.
                    
   If the return routability procedure completes successfully, a Binding
   Update message SHOULD be sent as described in Section 11.7.2.  The
   Lifetime field in this Binding Update SHOULD be set to a new
   lifetime, extending any current lifetime remaining from a previous
   Binding Update sent to this node (as indicated in any existing
   Binding Update List entry for this node), and lifetime SHOULD again
   be less than or equal to the remaining lifetime of the home
   registration and the care-of address specified for the binding.  When
   sending this Binding Update, the mobile node MUST update its Binding
   Update List in the same way as for any other Binding Update sent by
   the mobile node.
                    
                    
11.3.3 Receiving Packets While Away from Home
                    
   While away from home, a mobile node will receive packets addressed to
   its home address, by one of two methods:
                    
   o  Packets sent by a correspondent node that does not have a Binding
      Cache entry for the mobile node, will be sent to the home address,
      captured by the home agent and tunneled to the mobile node
                    
   o  Packets sent by a correspondent node that has a Binding Cache
      entry for the mobile node that contains the mobile node's current
      care-of address, will be sent by the correspondent node using a
      type 2 routing header.  The packet will be addressed to the mobile
      node's care-of address, with the final hop in the routing header
      directing the packet to the mobile node's home address; the
      processing of this last hop of the routing header is entirely
      internal to the mobile node, since the care-of address and home
      address are both addresses within the mobile node.
                    
(snip)
                    
   A node receiving a packet addressed to itself (i.e., one of the
   node's addresses is in the IPv6 destination field) follows the next
   header chain of headers and processes them.  When it encounters a
   type 2 routing header during this processing it performs the
   following checks.  If any of these checks fail the node MUST silently
   discard the packet.
                    
   o  The length field in the routing header is exactly 2.
                    
   o  The segments left field in the routing header is 1 on the wire.
      (But implementations may process the routing header so that the
      value may become 0 after the routing header has been processed,
      but before the rest of the packet is processed.)
                    
   o  The Home Address field in the routing header is one of the node's
      home addresses, if the segments left field was 1.  Thus, in
      particular the address field is required to be a unicast routable
      address.