MN-4-1-1-3-001 - Send and receive the packets (including type2 routing header and home address destination)
Host
|
HAcn CN0 NUTZ
| | |
-----+-------+--------+--------+------- LinkZ
|
R2 CN0Y NUTY
| | |
-----+-------+--------+--------+------- LinkY
|
R1 CN0X NUTX
| | |
-----+-------+-------+--------+--------+------- LinkX
| |
HA1 HA0 Node0 CN00 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 |
CN0 home link |
| HA0(Link0) |
3ffe:501:ffff:100:200:ff:fe00:a0a0 |
|
| HA1(Link0) |
3ffe:501:ffff:100:200:ff:fe00:a1a1 |
|
| 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 |
|
| HAcn(LinkZ) |
3ffe:501:ffff:104:200:ff:fe00:aaaa |
|
1. Selection Option
- IPsec Support between MN and HA: YES or NO
- Route Optimization support: YES
2. Position of Mobile Node
HA0 NUT0 R1 R2 CN0 HAcn
| | | | | |
| ----> | | | | | 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)
# Home Address destination option is included.
6. Send Binding Acknowledgement. (HA0 -> NUTX)
# Type2 routing header is included.
HA0 NUT0 R1 R2 CN0 HAcn
| | | | | |
| ====> | <-------------------- | | 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-1.Router Advertisement
# | | | | | |
# | | | | CN0Y |
# | | | | | |
# | | | | ----> | | 9-2.Router Advertisement
# | | | | | ----> | 9-3.Neighbor Solicitations
# | | | | | | 9-4.(no reply:3 seconds)
# | | | | | |
# | | | | | ----> | 9-5.Binding Update
# | | | | | <---- | 9-6.Binding Acknowledgement
#-------------------------------------------------------------------------------
| | | | | |
| ====> | <-------------------- | ====> | 10.Home Test Init
| ====> | <-------------------- | | 11.Care-of Test Init
| <==== | --------------------> | | 12.Care-of Test
| <==== | --------------------> | <==== | 13.Home Test
| | | | | |
| ====> | <-------------------- | | 14.Binding Update
| <==== | --------------------> | | 15.Binding Acknowledgement
| | | | | |
| | | | | | 16.(wait)
| | | | | |
| | <-------------------- | | 17.ICMP Echo Request
| | --------------------> | | 18.ICMP Echo Reply(*1)
| | | | | |
| ====> | <-------------------- | ====> | 19.Home Test Init
| ====> | <-------------------- | | 20.Care-of Test Init
| <==== | --------------------> | | 21.Care-of Test
| <==== | --------------------> | <==== | 22.Home Test
| | | | | |
| ====> | <-------------------- | | 23.Binding Update
| <==== | --------------------> | | 24.Binding Acknowledgement
| | | | | |
| | | | | | 25.(wait)
| | | | | |
| | <-------------------- | | 26.ICMP Echo Request
| | --------------------> | | 27.ICMP Echo Reply(*1)
| | | | | |
| ====> | <-------------------- | ====> | 28.Home Test Init
| <==== | --------------------> | <==== | 29.Home Test
| | | | | |
| ====> | <-------------------- | | 30.Binding Update
| <==== | --------------------> | | 31.Binding Acknowledgement
| | | | | |
| | <-------------------- | ====> | 32.ICMP Echo Request
| | --------------------> | <==== | 33.ICMP Echo Reply(*2)
| | | | | |
1. Send tunneled ICMP Echo Request. (out: HA0 -> NUTX, in: CN0 -> NUT0)
2. Receive reverse tunneled 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 tunneled Home Test. (out: HA0 -> NUTX, in: CN0 -> NUT0)
6. Receive reverse tunneled ICMP Echo Reply or [6].
(out: NUTX -> HA0, in: NUT0 -> CN0)
7. Receive Binding Update to CN0. (NUTX -> CN0)
# Home Address destination option is included.
8. [6] or Receive ICMP Echo Reply. (NUTX -> CN0)
# Home Address destination option is included.
#-------------------------------------------------------------------------------
# 9-1. Send Router Advertisement. (HAcn -> HAcn_allnode_multi)
# 9-2. Send Router Advertisement. (R2 -> R2_allnode_multi)
# 9-3. Receive Neighbor Solicitations. (CN0 -> HAcn)
# 9-4. (no reply)
# # Wait during a maximum of 3 seconds(RFC2461).
# 9-5. Receive Binding Update to HA0. (CN0Y -> HAcn)
# 9-6. Send Binding Acknowledgement. (HAcn -> CN0Y)
#-------------------------------------------------------------------------------
10. Send tunneled Home Test Init. (out: HA0->NUTX, in: CN0->NUT0)
11. Send tunneled Care-of Test Init. (out: HA0->NUTX, in: CN0Y->NUT0)
12. Receive reverse tunneled care-of Test. (out: NUTX->HA0, in: NUT0->CN0Y)
13. Receive reverse tunneled Home Test. (out: NUTX->HA0, in: NUT0->CN0)
14. Send tunneled Binding Update. (out: HA0->NUTX, in: CN0Y->NUT0)
# Home Address destination option is included.
# The Acknowledge(A) bit is set to ON.
15. Receive reverse tunneled Binding Acknowledgement.
(out: NUTX->HA0, in: NUT0->CN0Y)
# Type2 routing header is included.
16. (wait)
17. Send ICMP Echo Request. (CN0Y -> NUTX)
# Type2 routing header is included.
# Home Address destination option is included.
18. Receive ICMP Echo Reply. (NUTX -> CN0Y)
# Type2 routing header is included.
# Home Address destination option is included.
19. Send tunneled Home Test Init. (out: HA0->NUTX, in: CN0->NUT0)
20. Send tunneled Care-of Test Init. (out: HA0->NUTX, in: CN0Y->NUT0)
21. Receive reverse tunneled care-of Test. (out: NUTX->HA0, in: NUT0->CN0Y)
22. Receive reverse tunneled Home Test. (out: NUTX->HA0, in: NUT0->CN0)
23. Send tunneled Binding Update. (out: HA0->NUTX, in: CN0Y->NUT0)
# Home Address destination option is included.
# The Acknowledge(A) bit is set to ON.
24. Receive reverse tunneled Binding Acknowledgement.
(out: NUTX->HA0, in: NUT0->CN0Y)
# Type2 routing header is included.
25. (wait)
26. Send tunneled ICMP Echo Request. (CN0Y -> NUTX)
# Type2 routing header is included.
# Home Address destination option is included.
27. Receive ICMP Echo Reply. (NUTX -> CN0Y)
# Type2 routing header is included.
# Home Address destination option is included.
28. Send tunneled Home Test Init. (out: HA0->NUTX, in: CN0->NUT0)
29. Receive reverse tunneled Home Test. (out: NUTX->HA0, in: NUT0->CN0)
30. Send tunneled Binding Update. (out: HA0->NUTX, in: CN0Y->NUT0)
# Home Address destination option is included.
# The Acknowledge(A) bit is set to ON.
31. Receive reverse tunneled Binding Acknowledgement.
(out: NUTX->HA0, in: NUT0->CN0Y)
# Type2 routing header is included.
32. Send ICMP Echo Request. (CN0 -> NUTX)
# Type2 routing header is included.
33. Receive ICMP Echo Reply. (NUTX -> CN0)
# Home Address destination option is included.
Packet Format is:
10(and 19 and 28).Home Test Init
11(and 20).Care-of Test Init
12(and 21).Care-of Test
13(and 22 and 29).Home Test
14(and 23).Binding Update
15(and 24).Binding Acknowledgement
17.ICMP Echo Request
18.ICMP Echo Reply
30.Binding Update Data is:
IPv6 header (source = home agent
destination = care-of address of target)
ESP header
IPv6 header (source = care-of address of correspondent node
destination = home address of target)
Destination Option Header
Home Address option(home address of correspondent node)
Mobility header
Binding Update
Sequence=any
A=1
H=0
Lifetime=0
Home nonce Index
Care-of nonce Index
Authenticator
31.Binding Acknowledgement Data is:
IPv6 header (source = care-of address of target
destination = home agent)
ESP header
IPv6 header (source = home address of target
destination = care-of address of correspondent node)
Routing Header
Type2 Routing heder option(home address of correspondent node)
Mobility header
Binding Acknowledgement
Status=0
K=0
Sequence=any
Lifetime=any
Authenticator
(*1) PASS: CN0Y receives the ICMP Echo reply packet by route optimization.
Then, check whether this packet fills all of the following.
- The Destination Address is set to the Source Address
of ICMP Echo request[17 and 26](=Care-of address of Correspondent Node).
- The Source Address is set to the Destination Address
of ICMP Echo request[17 and 26](=Care-of address of Mobile Node).
- The Type2 routing header option is included, and,
- This option is placed as the right location.
- The Home Address field is set to the home address of Correspondent Node.
- The Home Address destination option is included, and,
- This option is placed as the right location.
- The Home Address field is set to the home address of Mobile Node.
(*2) PASS: CN0 receives the ICMP Echo reply packet by route optimization.
Then, check whether this packet fills all of the following.
- The Destination Address is set to the Source Address
of ICMP Echo request[32](=Home address of Correspondent Node).
- The Source Address is set to the Destination Address
of ICMP Echo request[32](=Care-of address of Mobile Node).
- The Type2 routing header option is not included.
- The Home Address destination option is included, and,
- This option is placed as the right location.
- The Home Address field is set to the home address of Mobile Node.
(draft-ietf-mobileip-ipv6-24.txt)
6.1 Mobility Header
The Mobility Header is an extension header used by mobile nodes,
correspondent nodes, and home agents in all messaging related to the
creation and management of bindings. The subsections within this
section describe the message types that may be sent using the
Mobility Header.
Mobility Header messages MUST NOT be sent with a type 2 routing
header, except as described in Section 9.5.4 for Binding
Acknowledgement. Mobility Header messages also MUST NOT be used with
a Home Address destination option, except as described in Section
11.7.1 and Section 11.7.2 for Binding Update. Binding Update List or
Binding Cache information (when present) for the destination MUST NOT
be used in sending Mobility Header messages. That is, Mobility
Header messages bypass both the Binding Cache check described in
Section 9.3.2 and the Binding Update List check described in Section
11.3.1 which are normally performed for all packets. This applies
even to messages sent to or from a correspondent node which is itself
a mobile node.
9.3.1 Receiving Packets with Home Address Option
Packets containing a Home Address option MUST be dropped if the given
home address is not a unicast routable address.
Mobile nodes can include a Home Address destination option in a
packet if they believe the correspondent node has a Binding Cache
entry for the home address of a mobile node. Packets containing a
Home Address option MUST be dropped if there is no corresponding
Binding Cache entry. A corresponding Binding Cache entry MUST have
the same home address as appears in the Home Address destination
option, and the currently registered care-of address MUST be equal to
the source address of the packet. These tests MUST NOT be done for
packets that contain a Home Address option and a Binding Update.
If the packet is dropped due the above tests, the correspondent node
MUST send the Binding Error message as described in Section 9.3.3.
The Status field in this message should be set to 1 (unknown binding
for Home Address destination option).
The correspondent node MUST process the option in a manner consistent
with exchanging the Home Address field from the Home Address option
into the IPv6 header and replacing the original value of the Source
Address field there. After all IPv6 options have been processed, it
MUST be possible for upper layers to process the packet without the
knowledge that it came originally from a care-of address or that a
Home Address option was used.
(snip)
9.3.2 Sending Packets to a Mobile Node
Before sending any packet, the sending node SHOULD examine its
Binding Cache for an entry for the destination address to which the
packet is being sent. If the sending node has a Binding Cache entry
for this address, the sending node SHOULD use a type 2 routing header
to route the packet to this mobile node (the destination node) by way
of its care-of address. However, the mobile node MUST not do this in
the following cases:
o When sending an IPv6 Neighbor Discovery [12] packet.
o Where otherwise noted in Section 6.1.
(snip)
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.
o The mobile node MAY choose to directly use one of its care-of
addresses as the source of the packet, not requiring the use of a
Home Address option in the packet. This is particularly useful
for short-term communication that may easily be retried if it
fails. Using the mobile node's care-of address as the source for
such queries will generally have a lower overhead than using the
mobile node's home address, since no extra options need be used in
either the query or its reply. Such packets can be routed
normally, directly between their source and destination without
relying on Mobile IPv6. If application running on the mobile node
has no particular knowledge that the communication being sent fits
within this general type of communication, however, the mobile
node should not use its care-of address as the source of the
packet in this way.
The choice of the most efficient communications method is
application specific, and outside the scope of this specification.
The APIs necessary for controlling the choice are also out of
scope.
o While not at its home link, the mobile node MUST NOT use the Home
Address destination option when communicating with link-local or
site-local peers, if the scope of the home address is larger than
the scope of the peer's address.
Similarly, the mobile node MUST NOT use the Home Address
destination option for IPv6 Neighbor Discovery [12] packets.
Detailed operation of these cases is described later in this section
and also discussed in [31].
For packets sent by a mobile node while it is at home, no special
Mobile IPv6 processing is required. Likewise, if the mobile node
uses any address other than any of its home addresses as the source
of a packet sent while away from home no special Mobile IPv6
processing is required. In either case, the packet is simply
addressed and transmitted in the same way as any normal IPv6 packet.
For packets sent by the mobile node sent while away from home using
the mobile node's home address as the source, special Mobile IPv6
processing of the packet is required. This can be done in the
following two ways:
Route Optimization
This manner of delivering packets does not require going through
the home network, and typically will enable faster and more
reliable transmission.
The mobile node needs to ensure that there exists a Binding Cache
entry for its home address so that the correspondent node can
process the packet (Section 9.3.1 specifies the rules for Home
Address Destination Option Processing at a correspondent node).
The mobile node SHOULD examine its Binding Update List for an
entry which fulfills the following conditions:
* The Source Address field of the packet being sent is equal to
the home address in the entry.
* The Destination Address field of the packet being sent is equal
to the address of the correspondent node in the entry.
* One of the current care-of addresses of the mobile node appears
as the care-of address in the entry.
* The entry indicates that a binding has been successfully
created.
* The remaining lifetime of the binding is greater than zero.
When these conditions are met, the mobile node knows that the
correspondent node has a suitable Binding Cache entry.
A mobile node SHOULD arrange to supply the home address in a Home
Address option, and MUST set the IPv6 header's Source Address
field to the care-of address which the mobile node has registered
to be used with this correspondent node. The correspondent node
will then use the address supplied in the Home Address option to
serve the function traditionally done by the Source IP address in
the IPv6 header. The mobile node's home address is then supplied
to higher protocol layers and applications.
Specifically:
* Construct the packet using the mobile node's home address as
the packet's Source Address, in the same way as if the mobile
node were at home. This includes the calculation of upper
layer checksums using the home address as the value of the
source.
* Insert a Home Address option into the packet, with the Home
Address field copied from the original value of the Source
Address field in the packet.
* Change the Source Address field in the packet's IPv6 header to
one of the mobile node's care-of addresses. This will
typically be the mobile node's current primary care-of address,
but MUST be an address assigned to the interface on the link
being used.
By using the care-of address as the Source Address in the IPv6
header, with the mobile node's home address instead in the Home
Address option, the packet will be able to safely pass through any
router implementing ingress filtering [26].
(snip)
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)
For packets received by the second method, the following rules will
result in the packet being processed normally by upper-layer
protocols within the mobile node, as if it had been addressed to the
mobile node's home address.
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.
(snip)