MN-3-4-1-2-001 - Starting the return routability procedure (when receiving BRR)
Host
|
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 |
|
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)
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
(*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.
(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.