NAME

MN-4-1-1-2-005 - Sending the packets after deleting the BUL entry


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
 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 to HA0. (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.(wait)
        |       |       |       |        |
        |       | <--------------------- | 10.ICMP Echo Request
        | <==== | ---------------------> | 11.ICMP Echo Reply (*1)
        |       |       |       |        | 
                    
        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 ICMP Echo Reply or [8]. (out: NUTX -> HA0, in: NUT0 -> CN0)
        7. Receive Binding Update to CN. (NUTX -> CN0)
        8. [6] or Receive ICMP Echo Reply. (NUTX -> CN0)
        9. (wait)
            # Wait during the lifetime in the Lifetime field of Binding Update[7].
       10. Send ICMP Echo Request. (CN0 -> NUTX)
            # Type2 Routing Header is included.
       11. Receive ICMP Echo Reply. (out: NUTX -> HA0, in: NUT0 -> CN0)
                    


JUDGEMENT

 (*1) PASS: CN0 receives tunneled ICMP Echo Reply.


REFERENCE

                    
(draft-ietf-mobileip-ipv6-24.txt)
                    
11.3.1 Sending Packets While Away from Home
                    
   While a mobile node is away from home, it continues to use its home
   address, as well as also using one or more care-of addresses.  When
   sending a packet while away from home, a mobile node MAY choose among
   these in selecting the address that it will use as the source of the
   packet, as follows:
                    
   o  Protocols layered over IP will generally treat the mobile node's
      home address as its IP address for most packets.  For packets sent
      that are part of transport-level connections established while the
      mobile node was at home, the mobile node MUST use its home
      address.  Likewise, for packets sent that are part of
      transport-level connections that the mobile node may still be
      using after moving to a new location, the mobile node SHOULD use
      its home address in this way.  If a binding exists, the mobile
      node SHOULD send the packets directly to the correspondent node.
      Otherwise, if a binding does not exist, the mobile node MUST use
      reverse tunneling.
                    
(snip)
                    
   Reverse Tunneling
                    
                    
      This is the mechanism which tunnels the packets via the home
      agent.  It is not as efficient as the above mechanism, but is
      needed if there is no binding yet with the correspondent node.
                    
      This mechanism is used for packets that have the mobile node's
      home address as the Source Address in the IPv6 header, or with
      multicast control protocol packets as described in Section 11.3.4.
      Specifically:
                    
      *  The packet is sent to the home agent using IPv6 encapsulation
         [15].
                    
      *  The Source Address in the tunnel packet is the primary care-of
         address as registered with the home agent.
                    
      *  The Destination Address in the tunnel packet is the home
         agent's address.
                    
                    
      Then, the home agent will pass the encapsulated packet to the
      correspondent node.
                    
                    
11.3.3 Receiving Packets While Away from Home
                    
(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.
                    
   Once the above checks have been performed, the node swaps the IPv6
   destination field with the Home Address field in the routing header,
   decrements segments left by one from the value it had on the wire,
   and resubmits the packet to IP for processing the next header.
   Conceptually this follows the same model as in RFC 2460.  However, in
   the case of type 2 routing header this can be simplified since it is
   known that the packet will not be forwarded to a different node.