Movement detection - layer2 trigger

1. Movement detection - layer2 trigger

2. Outline • Background • Link-layer trigger • Detection of Network Attachment in IPv4 (DNAv4) • Detection of Network Attachment in IPv6 (DNAv6)

3. Background, Movement Detection

4. AR1 AR2 AR3 Cell 1 Cell 2 Cell 3 AP1 AP2 AP3 Background, Movement Detection Each AR advertises the different prefix. Internet There are 3 Wireless Cell for 3 APs. A:: B:: C::

5. AR1 AR2 AR3 Link 2 Link 1 AP1 AP2 AP3 Background, Movement Detection Each AR advertises the different prefix. Internet There are 3 Wireless Cell for 3 APs. There are only 2 links. A:: B:: C:: * Link: a communication facility or medium over which nodes can communicate at the link layer

6. AR1 AR2 AR3 MN Cell 1 Cell 2 Cell 3 AP1 AP2 AP3 Background, Movement Detection 1. MN is attached to AR1 via AP1 Internet A:: B:: C::

7. AR1 AR2 AR3 MN Cell 1 Cell 2 Cell 3 AP3 AP2 AP1 Background, Movement Detection 1. MN is attached to AR1 via AP1 2. MN changes its attachment to AP2 and link change has occurred. Internet A:: B:: C::

8. AR1 AR2 AR3 MN Cell 1 Cell 2 Cell 3 AP3 AP2 AP1 Background, Movement Detection 1. MN is attached to AR1 via AP1 2. MN changes its attachment to AP2 and link change has occurred. Internet 3. MN changes its attachment to AP3 but still remains at the same link. A:: B:: C::

9. AR1 AR2 AR3 MN Cell 1 Cell 2 Cell 3 AP3 AP2 AP1 Background, Movement Detection 1. DNAv6 have to detect movement quickly when MN moves from Cell 1 to Cell2. Internet 2. MN should not falsely assume movement when MN moves from Cell 2 to Cell 3. A:: B:: C::

10. Link-layer trigger

11. General Trigger Model (1/2) • In general, handoffs can be initiated either by the mobile node or by the remote network node. • Different 802 network types follow different rules as to which end makes handover decisions. - E.G. in 802.16 it is the base station (BS), in 802.11 it is the STA.

12. General Trigger Model (2/2) • This suggests that triggers need to carry some identification of the source from where they came. • This source identifier needs to include what layer in the stack is came from and whether it is from the local or remote stack. In shared media, peer to peer networks, such as 802.3, a MAC address would be required to distinguish between the possible end points.

13. Link Going Down • A Link_Going_Down trigger implies that a Link_Down is imminent within a certain time interval. If Link_Down is NOT received within specified time interval then actions due to previous Link_Going_Down may be discarded. • Another Link_Going_Down trigger can be received only after specified time interval has elapsed. Link_Going_Down trigger may be used as a signal to initiate handoff procedures.

14. Link Going Up • Link_Going_Up is used in cases wherein the wireless network takes a long time to initialize. • In such cases the pending availability of a particular type of network may influence decisions related to Network Detection and Selection at Layer 3 and to initiating handover procedures from an existing connection.

15. Trigger Rollback • Trigger_Rollback is used in conjunction with Link_Going_Up and Link_Going_Down. • In case of Link_Going_Down in the time interval that the link is expected to go down, if things start going otherwise and if the link actually starts going up, then a Trigger_Rollback message is sent to the Trigger Destination. Similarly in case of Link_Going_Up in the time interval that the link is expected to go up, if things start going otherwise and if the link actually starts going down, then a Trigger_Rollback message is sent to the Trigger Destination. The Destination should disregard or rollback the changes associated with the trigger ID in such cases.

16. Link Going Up with Rollback

17. Link Going Down with Rollback

18. L3 Handover with L2 hints

19. Detection of Network Attachment in IPv4(DNAv4)

20. Why the Interest in DNAv4? • Discussion in ZEROCONF WG on use of IPv4 linklocal addresses • Today’s hosts are often mobile • May or may not implement Mobile IP. • IP configuration latency a significant fraction of total roaming latency (>50%) • Assignment of an IPv4 linklocal address typically the result of a bug in the host or a network fault, not detection of an adhoc network • How do we make address assignment more resilient? • Less likely to assign IPv4 linklocal addresses inappropriately • Able to recover from an IPv4 LL assignment • Able to quickly recognize when they have reattached to the same subnet • Able to quickly obtain an address & configuration when they have connected to a new subnet

21. DNAv4 Model • “Hints” – non-definitive indications whether the host has connected to a previously encountered subnet • L2 hints: 802.11 SSID, Infrastructure/Adhoc, IEEE 802 LLDP traffic • L3 hints: IRDP • “Most Likely” point of attachment (POA) • Best guess, based on hints • By default: previous point of attachment • Reachability detection • ARP Request sent to “most likely” default gateway • Address re-acquisition • Used only if client retains a valid lease • DHCPREQUEST sent in INIT-REBOOT state

22. DNAv4 Strawman Proposal • Formulate “most likely” point of attachment • Is IPv4 LL ever “most likely” ? • Probably not • May wish to test reachability to all networks with valid IP leases prior to configuring an IPv4 LL address • Check for valid IP address lease (<T1) • If valid, perform reachability detection on default gateway of “most likely” network • If reachability succeeds, reuse address • Note: To handle movement between private networks, need to match *both* IP address and MAC address of default gateway • If reachability fails send DHCPREQUEST in INIT-REBOOT state • If no valid IP address lease, or no response to DHCPREQUEST after retransmission, go to INIT state • If DHCP fails, do we allocate IPv4 LL address? • Empirical evidence is that this is invalid much of the time, but it could be required. • If IPv4LL is allocated, how often do we attempt to obtain a routable IP address?

23. What RFC 4436 Says (1) • Section 2.2: • “As a consistency check, the allocating server SHOULD probe the reused address before allocating the address, e.g., with an ICMP echo request, and the client SHOULD probe the newly received address, e.g., with ARP.” • Section 3.1: • The client should choose to retransmit the DHCPREQUEST enough times to give adequate probability of contacting the server without causing the client (and the user of that client) to wait overly long before giving up; e.g., a client retransmitting as described in section 4.1 might retransmit the DHCPREQUEST message four times, for a total delay of 60 seconds, before restarting the initialization procedure.

24. What RFC 4436 Says (2) • Section 3.2: • “If the client receives neither a DHCPACK or a DHCPNAK message after employing the retransmission algorithm, the client MAY choose to use the previously allocated network address and configuration parameters for the remainder of the unexpired lease.” • “Note that in this case, where the client retains its network address locally, the client will not normally relinquish its lease during a graceful shutdown.” • Section 3.7: • “A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network, as the local network configuration may change without the client's or user's knowledge. • If a client has knowledge of a previous network address and is unable to contact a local DHCP server, the client may continue to use the previous network address until the lease for that address expires. If the lease expires before the client can contact a DHCP server, the client must immediately discontinue use of the previous network address and may inform local users of the problem.

25. What draft-ietf-zeroconf-IPv4-Linklocal-08 Says • Section 1.6: • “While [RFC2131] indicates that a DHCP client SHOULD probe a newly received address with ARP, this is not mandatory. Similarly, while [RFC2131] recommends that a DHCP server SHOULD probe an address using an ICMP Echo Request before allocating it, this is also not mandatory, and even if the server does this, Link-Local IPv4 addresses are not routable, so a DHCP server not directly connected to a link cannot detect whether a host on that link is already using the desired Link-Local IPv4 address.”

26. A Bad Idea if Taken Literally • Section 2.2 • “After it has selected a Link-Local IPv4 address, a host MUST test to see if the Link-Local IPv4 address is already in use before beginning to use it. When a network interface transitions from an inactive to an active state, the host does not have knowledge of what Link-Local IPv4 addresses may currently be in use on that link, since the network interface may have been inactive when a conflicting address was claimed.” • Implications • Host connects to an adhoc POA, selects IPv4LL address • Host moves to another (configured) POA • Performs IPv4LL claim and defend • Uses selected IPv4LL address • Host never obtains a routable address! • Solution • IPv4LL as a last resort

27. Summary • Detecting Network Attachment (DNA) is an important aspect of mobility • Poor implementation can result in mobile hosts that are never connected! • 802.1X + pre-mature DHCP + LLv4 + 5 minute timeout • Naïve IPv4LL implementation • Some grey areas in RFC 2131, IPv4 LL specifications • Question: Where should this work be handled?

28. Detection of Network Attachment in IPv6(DNAv6)

29. DNAv6 Overview • Upon a new link layer connection, a host may or may not have a valid IP configuration. It may ascertain the validity of its IP configuration by checking link change.

30. Internet AR1 AR2 N AP1 AP2 DNAv6, rough sketch 0. Node N is attached to AR1 via AP1.

31. Internet AR1 AR2 N AP1 AP2 DNAv6, rough sketch 0. Node N is attached to AR1 via AP1. 1. N make an access to AR2 via AP2, a new link-layer connection has been established. 2. N receives a hint that link change may have occurred. 3. N checks whether it still is at the same link. - If so, it can still reach its current AR and don’t need to perform DNAv6 anymore. 4.If not, a node discovers a new AR with the prefix information. - N receives a RA and checks the prefixes in it. 5.In case its IP address is no longer valid, N forms a new IP address.

32. Internet AR1 AR2 N AP1 AP2 DNAv6, rough sketch 0. Node N is attached to AR1 via AP1. 1. N make an access to AR2 via AP2, a new link-layer connection has been established. 2. N receives a hint that link change may have occurred. 3. N checks whether it still is at the same link. - If so, it can still reach its current AR and don’t need to perform DNAv6 anymore. 4.If not, a node discovers a new AR with the prefix information. - N receives a RA and checks the prefixes in it. 5.In case its IP address is no longer valid, N forms a new IP address.

33. DNAv6 Process • Step1: Hint • Step2: Detecting the link change. • Checking the reachability of current default router. • Step3: Router Discovery with the prefix information. • Checking the validity of current IP address

34. DNAv6 Methods • Step1: Hint • Link layer hint • New RA message • RA beaconing • Step2: Checking the Link change. • Checking the reachability of current default router. • NUD like (3 NSs) • 1 NS and timeout • RA beaconing • Step3: Router Discovery with the prefix information. • RS/ RA exchange

35. DNAv6 Problems • No means to represent a link • In RA message, neither router address nor prefixes can do it. • Link-layer hint can’t detect Link change by itself. • The ambiguity of RA information • Link local scope of router address • Prefix omission • The delay to check the reachability of current AR • It’s difficult to detect something is NOT there. • Roughly 3 secs for NUD • Random Delay in RS/ RA exchange • No agreed way to do DNAv6

36. DNAv6 Goals with Requirements • Update a RA message format, which • can represent a link • doesn’t have performance degrading ambiguities. • Specify a operational procedure, which • can quickly detect link change • can quickly receive a RA with the prefix information. • Define a DNAv6 scheme such that • Fast: low time delay • Precise/ Secure: Little error • Efficient: limit signaling (NS/NA or RS/RA)

37. DNAv6 Goals 1. DNA schemes should ascertain the validity of current IP configuration by detecting currently attached link. It should recognize and determine whether IP configuration change is needed and initiate a new configuration if necessary. 2. DNA schemes should detect link change fast to prevent service disruption. 3. DNA schemes should not assume link change erroneously.

38. DNAv6 Goals 4. DNA schemes should not cause undue signaling on a wireless link. 5. DNA schemes should make use of existing signaling mechanisms where available. 6. DNA schemes should make use of signaling within the link

39. DNAv6 Goals 7. DNA schemes should be safe with respect to DAD. 8. DNA schemes should be compatible with existing IP security schemes (SEND, IPSec) 9. A host configured for DNA should not expose the host to additional man in the middle or identity revealing attacks.

40. DNAv6 Goals 10. A host or router configured for DNA should not expose itself or other devices on the link to additional denial of service attacks 11. Routers Supporting DNA should work appropriately with hosts using unmodified configuration schemes. 12. Hosts supporting DNA should be able to work with unmodified routers and hosts which do not support DNA solutions.

41. Renumbering Issue • Should DNAv6 solution take in consideration the problems caused by renumbering? • Maybe No • Renumbering is usually well advertised beforehand. • Renumbering has nothing to do with link change. • Renumbering is independent of a new link-layer connection.

42. Conclusion • 移動性管理 • Detecting Network Attachment (DNA) • DNAv6 • If the RA includes a prefix that matches an entry in its DNAHostPrefixList, then the host SHOULD conclude that no link change has occurred and the current configuration can be assumed to still be current.