Movement detection - layer2 trigger

Outline

• Background

• Link-layer trigger

• Detection of Network Attachment in IPv4 (DNAv4)

• Detection of Network Attachment in IPv6 (DNAv6)

3

A R 1 A R 3

A R 2

H A C N

R o u t e r 2

R o u t e r 1

A : :

A P 1

A P 2

A P 3

B : :

C : :

C e l l 1

H u b

C e l l 3

M N

C e l l 2

Background, Movement Detection

4

Internet

AR1

AP1 AP2

AR2 AR3

AP3

Cell 1 Cell 2 Cell 3

There are 3 Wireless Cell for 3 APs.

Each AR advertises the different prefix.

A:: B:: C::

Background, Movement Detection

5

Internet

AR1

AP1 AP2

AR2 AR3

AP3

There are only 2 links.

Link 1 Link 2

There are 3 Wireless Cell for 3 APs.

Each AR advertises the different prefix.

A:: B:: C::

Background, Movement Detection

* Link: a communication facility or medium over which nodes can communicate at the link layer

6

Internet

AR1

AP1 AP2

AR2 AR3

AP3

1. MN is attached to AR1 via AP1

Cell 1 Cell 2 Cell 3

MN

A:: B:: C::

Background, Movement Detection

7

Internet

AR1

AP1 AP2

AR2 AR3

AP3

1. MN is attached to AR1 via AP1

2. MN changes its attachment to AP2 and link change has occurred.

MN

Cell 1 Cell 2 Cell 3

A:: B:: C::

Background, Movement Detection

8

Internet

AR1

AP1 AP2

AR2 AR3

AP3

1. MN is attached to AR1 via AP1

2. MN changes its attachment to AP2 and link change has occurred.

Cell 1 Cell 2 Cell 3

MN

A:: B:: C::

Background, Movement Detection

3. MN changes its attachment to AP3 but still remains at the same link.

9

Internet

AR1

AP1 AP2

AR2 AR3

AP3

Cell 1 Cell 2 Cell 3

MN

A:: B:: C::

Background, Movement Detection

1. DNAv6 have to detect movement quickly when MN moves from Cell 1 to Cell2.

2. MN should not falsely assume movement when MN moves from Cell 2 to Cell 3.

Link-layer trigger

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.

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.

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.

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.

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.

Link Going Up with Rollback

Link Going Down with Rollback

L3 Handover with L2 hints

Detection of Network Attachment in IPv4(DNAv4)

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 subne

t• Able to quickly obtain an address & configuration when they have conne

cted to a new subnet

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 traf

fic– 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

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 addres

s – Check for valid IP address lease (<T1)– If valid, perform reachability detection on default gateway of “most likely” net

work• 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 retransmis

sion, 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?

What RFC 4436 Says (1)

• Section 2.2:– “As a consistency check, the allocating server SHOULD probe th

e 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 eno

ugh 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.

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 netwo

rk 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.

What draft-ietf-zeroconf-IPv4-Linklocal-08 Says

• Section 1.6:– “While [RFC2131] indicates that a DHCP client SHOUL

D 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.”

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

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?

Detection of Network Attachment in IPv6(DNAv6)

29

• 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.

DNAv6 Overview

30

0. Node N is attached to AR1 via AP1.

DNAv6, rough sketch

Internet

AR1

N

AP1 AP2

AR2

31

0. Node N is attached to AR1 via AP1.

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.

DNAv6, rough sketch

- 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.

Internet

AR1

N

AP1 AP2

AR2

1. N make an access to AR2 via AP2, a new link-layer connection has been established.

32

DNAv6, rough sketch

Internet

AR1

N

AP1 AP2

AR2

0. Node N is attached to AR1 via AP1.

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.

1. N make an access to AR2 via AP2, a new link-layer connection has been established.

33

• 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

DNAv6 Process

34

• 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

DNAv6 Methods

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

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.

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.

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

• 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.

Renumbering Issue

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.