Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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 MN1AR1 AR1tunnel MN1on-link AR1 MN1 AR2 Route/Tunnel Configuration After MN moves to AR2 MN1AR2 AR2tunnel AR1 AR2 MN1on-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?