Transcript Sub4_1_3_4_layer 2 trigger,DNAv4,DNAv6

Movement detection - layer2
trigger
Outline
• Background
• Link-layer trigger
• Detection of Network Attachment in IPv4
(DNAv4)
• Detection of Network Attachment in IPv6
(DNAv6)
Background, Movement Detection
3
Background, Movement Detection
Each AR advertises the different
prefix.
Internet
AR1
A::
There are 3 Wireless Cell for 3
APs.
AR2
B::
AP1
AP2
Cell 1
Cell 2
AR3
C::
AP3
Cell 3
4
Background, Movement Detection
Each AR advertises the different
prefix.
Internet
AR1
A::
AP1
Link 1
There are 3 Wireless Cell for 3
APs.
AR2
There are only 2 links.
AR3
B::
C::
AP2
AP3
Link 2
* Link:
a communication facility
or medium over which
nodes can communicate
5
at the link layer
Background, Movement Detection
1. MN is attached to AR1 via AP1
Internet
AR1
AR2
A::
B::
AP1
AP2
Cell 1
Cell 2
MN
AR3
C::
AP3
Cell 3
6
Background, Movement Detection
1. MN is attached to AR1 via AP1
2. MN changes its attachment to
AP2 and link change has
occurred.
Internet
AR1
A::
AR2
AR3
B::
AP1
AP2
Cell 1
Cell 2
C::
AP3
Cell 3
MN
7
Background, Movement Detection
1. MN is attached to AR1 via AP1
2. MN changes its attachment to
AP2 and link change has
occurred.
Internet
AR1
A::
AR2
B::
AP1
AP2
Cell 1
Cell 2
3. MN changes its attachment to
AP3 but still remains at the
same link.
AR3
C::
AP3
Cell 3
MN
8
Background, Movement Detection
1. DNAv6 have to detect
movement quickly when MN
moves from Cell 1 to Cell2.
Internet
AR1
A::
AR2
B::
AP1
AP2
Cell 1
Cell 2
2. MN should not falsely assume
movement when MN moves
from Cell 2 to Cell 3.
AR3
C::
AP3
Cell 3
MN
9
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
subnet
• Able to quickly obtain an address & configuration when they have
connected 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
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
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?
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.
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.
What draft-ietf-zeroconf-IPv4Linklocal-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.”
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)
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.
29
DNAv6, rough sketch
0. Node N is attached to AR1 via AP1.
Internet
AR1
AR2
AP1
AP2
N
30
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.
Internet
AR1
AP1
N
AR2
2. N receives a hint that link change
may have occurred.
AP2
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.
31
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.
Internet
AR1
AP1
N
AR2
2. N receives a hint that link change
may have occurred.
AP2
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
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
33
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
34
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)
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.
37
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
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.
39
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.
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 linklayer connection.
41
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.