Network Localized Mobility Management using DHCP draft-templin-autoconf-netlmm-dhcp-04 fred.l.templin@boeing.com IETF67 –DHCP wg

NETLMM Problem Space Global Internet NETLMM Domain A Domain B Mobile Nodes localized mobility 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 AR2 MN1

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, network-initiated handovers and address registration proxy for non-DHCP MNs Access network Backhaul eth1 eth0 Access Router DHCP Client DHCP Relay lo0

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 Information-request 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 Information-request 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 Info-request/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?