Transcript PPT Version

Network Localized Mobility
Management using DHCP
draft-templin-autoconf-netlmm-dhcp-04
[email protected]
IETF67 –DHCP wg
NETLMM Problem Space
Global Internet
NETLMM
Domain A
localized
mobility
NETLMM
Domain B
Mobile
Nodes
NETLMM
Domain A
global mobility
(out-of-scope)
Problem Statement and Goals
• support NETLMM domains as small as a home network
or as large a major operator network, e.g., metropolitan
region WiFi, cellular, etc.
• MNs keep same addresses/prefixes as they move within
a NETLMM domain (global mobility out-of-scope)
• support session continuity across mobility events
• reduce routing churn (avoid tracking MNs via IGP)
• Problem Statement: draft-ietf-netlmm-nohost-ps-05.txt
• Goals: draft-ietf-netlmm-nohost-req-05.txt
– TODO: match up NETLMM/DHCP proposal with goals
NETLMM Domain
Backhaul Network
Access Rtrs (ARs)
Mobility Anchor
Point(s) (MAPs)
Access Networks
Mobile Nodes (MNs)
NETLMM Using DHCP
• Let each MN be a DHCP client
• Let each AR be a DHCP Relay
• Let each MAP be associated with a DHCP
server (no need for them to be co-located)
Route/Tunnel Configuration after
MN config’s address/prefix via AR1
MN1AR1
AR1tunnel
MN1on-link
AR1
MN1
AR2
Route/Tunnel Configuration After
MN moves to AR2
MN1AR2
AR2tunnel
AR1
AR2
MN1on-link
MN1
New since -02 version
(current version is -04)
• AR now has DHCP client co-resident with
DHCP relay
• Fast/reliable mechanism for deleting stale
state in old AR (missing in -02)
• Network-initiated handovers
• Support for SLAAC-only Mobile Nodes
(aka “Proxy-DHCP”)
• (Only discussing IPv6 here, but IPv4 also
supported)
AR Client/Relay Configuration
• DHCP client/relay co-resident; use lo0 interface
• Relay responsible for managing IP forwarding table
(examines messages for RAAN options, aka CSRs)
• Client responsible for reliable exchanges, networkinitiated handovers and address registration proxy for
non-DHCP MNs
DHCP Client lo0 DHCP Relay
Access
network
eth0
Access Router
Backhaul
network
eth1
Deleting State in Old AR
• MAP performs handover exchange with new AR via
MN’s Confirm/Rebind (or network-initiated handover)
• MAP sends Reconfigure to old AR
• Old AR’s client function sends Information-Request to
MAP wrapped in Relay-forward message
• MAP sends Reply with CSR options to old AR’s client
function via old AR’s relay function
Network-initiated handovers
• New AR detects MN coming onto its link via L2 signal
• New AR’s client function sends immediate Informationrequest to MAP (wrapped in Relay-forward message)
with CSR option that includes Client ID option with DUID
for client
• MAP sends Reply to new AR’s client function with CSR
options for MN via new AR’s relay function
• MAP sends simultaneous Reconfigure to old AR’s client
function to delete old state
Support for SLAAC-only MNs
(aka “Proxy-DHCP”)
• SLAAC-only MN sends NS(DAD) for tentative address
• AR’s client function sends immediate Informationrequest to MAP (wrapped in Relay-forward message)
with CSR option with IA_NA that encapsulates the
tentative address and Client ID for client
• MAP sends Reply to AR’s client function with CSR
options for MN via new AR’s relay function
• Proxy-DAD needed in case MAP detects duplicate (TBD)
Notes
• Use Server Reply Sequence Number
(SRSN) wherever RAAN options are used
• Allow AR’s client function to act as both
“Responder” for NETLMM signaling and
ordinary client for AR auto-configuration
• Need to specify proxy/relay-DAD so that
MNs using SEND/CGA that configure
duplicate addresses will be detected
Technical Questions
• Can we rename RAAN as “Classless Static
Route (CSR) option for DHCPv6”? Reasons:
– symmetry with DHCPv4
– “promotes” existing DHCPv4 option to DHCPv6
– simplifies documentation (“CSR” used for both
DHCPv6; DHCPv4)
• Can Reconfigure message carry CSR options
(instead of waiting for Info-request/Reply)?
• Can Solicit/Reply be used instead of Inforequest/Reply for “Proxy-DHCP”?
Big-Picture Questions
• Should there be a DHCP wg liaison to the
NETLMM wg?
• Can this work be combined with the
NETLMM design team specification as
input for a possible DHCPv6(bis) effort?
• Can this work be taken as a DHCP wg
item?