IPv6 Neighbor Cache Update
Hiroshi KITAMURA NEC Corporation
[email protected] 1
Index • Introduction / Background • Problems – on (Not-Used) Long Remained NC entries.
• Proposed Solutions (Neighbor Cache Update (Delete)) – Heuristic Type: (w/o any ND message extensions) – Explicit Type: (w/ small extension (NA flags)) – Explicit + Heuristic Combined Type
• Implementation
2
Introduction / Background IP address’s “Using Status” Status is frequently changed
“Used” “Not Used” •
Disconnecting / Connecting nodes from/to networks at mobile environments • Suspending / Hibernating / Resuming nodes – Turn Off / On PCs – Release / Discover IP address by DHCP • Utilize Changeable-type Addresses: Temporary Address / Ephemeral Address* * 3
Problems on (Not-Used) Remained Neighbor Cache Entries • What’s happens when (IP address is gone) IP address’s Using Status is changed form “Used” to “Not Used” ? • Related Neighbor Cache Entries (that are created for the “Gone IP addresses”) are not deleted and still remained for a long time (typically 24 hours). 4
Example: (Not-Used) Long Remained NC entries 1/2 Neighbor Cache IP_1 Client
Server X
Server Y
Server side Edge Router
Internet
Client side IP_R Edge Router
A
IP_R
L2_R
IP_2
Client B
IP_R
L2_R
IP_3
Client C
IP_R
L2_R
D
IP_R
L2_R
Client E
IP_R
L2_R
Neighbor Cache Server Z
IP
L2
IP_1
L2_A
IP_2
L2_B
IP_3
L2_C
IP_4
L2_D
IP_5
L2_E
IP_4 Client
IP_5
5
Example: (Not-Used) Long Remained NC entries 2/2 IP_1 Client
Server X
Server Y
Server side Edge Router
Internet
Gone (NotUsed)
Client side IP_R Edge Router
A
IP_2
Client B
IP_3
Client C
Neighbor Cache Server Z
(Not-Used) NC entries Still Remained for a long time
IP
L2
IP_1
L2_A
IP_2
L2_B
IP_3
L2_C
IP_4
L2_D
IP_5
L2_E
IP_4 Client
bu
D
t IP_5
Client E
6
Why Not-Used NC entries are remained? • NC state procedures are showed in right figure that is defined in ND specification [RFC4861].
• Not-Used NC entries are remained at STALE state for a long time and finally they are deleted by the “garbage collections”.
Edge Router
Client
NC State NS
INCOMPLETE
NA
REACHABLE
IP address is Gone STALE
bu
t
(Not-Used) NC entry
Remained long time 7
Characteristics on (Not-Used) Long Remained NC entries
It is clear: – from efficient resource management viewpoint: NOT Good. – from security enhancement viewpoint: NOT Good.
8
What should we do? • We have to follow the manner:
“Leave everything neat and tidy when you go behind you” • When using status of an IP address is changed from “Used” to “Not-Used”, its related cache entry should be deleted cooperatively. • We have to provide quick and clear neighbor cache update (delete) functions. 9
Proposed Solutions: Neighbor Cache Update (Delete) Methods Three types of Neighbor Cache Update (delete) methods are proposed. 1. Heuristic Type: Does NOT require any ND message extensions 2. Explicit Type: Requires small extensions (NA message Flags) 3. Explicit + Heuristic Combined Type: Any types of nodes are supported effectively 10
Heuristic Type Neighbor Cache Update • Stimulate the remaining STALE (inactivated) NC entry by sending the special NS message (source = Gone IP address) from client node. • (The target NC entry is activated by issuing NA.) Its state is proceeded to next state DELAY and finally the target NC entry is deleted. • Takes short time periods for DELAY and PROBE states.
Edge Router
NC State NS
INCOMPLETE
NA
REACHABLE u-NA
DELAY
IP addr is Gone.
NS
STALE
PROBE
• No ND message extensions are required.
Client
NA
Stimulate
NS NS NS
NC entry deleted 11
Explicit Type: Neighbor Cache Update • Issue an Extended NA message (+extended flags) to delete target NC entry from client node. • If a receiver node understands the extended flags, the target NC entry is quickly deleted. • If the node does not understand, the message is simply ignored. (the NC entry is not deleted and errors are not reported.)
Edge Router
Client
NC State NS
INCOMPLETE
NA
REACHABLE u-NA
STALE
IP addr is Gone.
NA for delete
NC entry deleted
12
Explicit Type: NA Message Flags Extensions 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|O|D|F| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-
D: Delete flag (Delete entry except its state is REACHABLE) F: Force Delete flag (Force to delete entry at any states) 13
Explicit + Heuristic Combined Type Neighbor Cache Update Edge Router
• Support both types of nodes that do and do not understand the NA extensions effectively.
NC State NS
INCOMPLETE
NA
– Nodes do understand extensions: the entry is deleted quickly by REACHABLE the 1st Explicit operation. – Nodes do not understand extensions: STALE the entry is deleted shortly by NC deleted ? the 2nd Heuristic operation.
• In any node cases, the target NC entry is surely deleted.
Client
DELAY
PROBE Surely NC deleted
u-NA
IP addr is Gone.
NA for delete NS NA
Stimulate
NS NS NS
14
Implementations • Proposed all “Neighbor Cache Update ” specification has been implemented and verified. • Delete Responder (Edge Router) type: – Explicit Type: • FreeBSD
– Heuristic Type: • IOS, Linux, FreeBSD, MacOS X, Windows, etc.
• Delete Initiator (Client) type: – Explicit / Heuristic Type: (Verified) • FreeBSD
– Explicit / Heuristic Type: (Under Developing) • Linux, MacOS X, Windows, etc.
15
Consensus Verification to Proposed Methods Which methods do you prefer? 1. Heuristic Type: Does NOT require any ND message extensions 2. Explicit Type: Requires small extensions (NA message Flags) 3. Explicit + Heuristic Combined Type: Any types of nodes are supported effectively [Authors recommend this type method]
16
Related Issues • Same types of problems can be found in IPv4 ARP table entries. • How do we have to deal with it?
17
