Network Localized Mobility Management using DHCP

1. Network Localized Mobility Management using DHCP fred.l.templin@boeing.com

2. Global Internet NETLMM Domain A NETLMM Domain A NETLMM Domain B Mobile Nodes localized mobility NETLMM Problem Space global mobility (out-of-scope)

3. NETLMM Goals • support NETLMM domains as small as a home network or as large a major operator network, e.g., metropolitan region WiFi • MNs keep same addresses/prefixes as they move within a NETLMM domain (global mobility out-of-scope) • support session continuity across mobility events • avoid routing churn by having Mobility Anchor Points that aggregate the NETLMM domain (as opposed to tracking node mobility via a routing protocol)

4. NETLMM Domain Backhaul Network Access Rtrs (ARs) Mobility Anchor Point(s) (MAPs) Access Networks Mobile Nodes (MNs)

5. 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)

6. Model of Operation • MN discovers ARs via RFC2461 Router Advertisements (RAs) • If RAs contain prefix options, MN can configure addresses using RFC2462, then “register” them with the network by sending DHCP Solicit/Request with IP address options • If RAs contain no prefix options, or if prefix delegation is desired, MN requests prefixes by sending DHCP Solicit/Request per RFC3633 • AR relays DHCP Solicit/Request to a DHCP server associated with a MAP

7. Model of Operation (cont’d) • DHCP server registers addresses/prefixes, then issues “create tunnel”; “route add” to update MAP IP forwarding table(s) • DHCP server sends reply to MN which is intercepted by AR; AR performs a local “route add” • Now, traffic from the Internet destined to MN flows through the MAP(s) and is directed to the correct AR • If MN moves to a new AR, MN issues a DHCP Confirm which causes the MAPs and ARs to update their IP forwarding tables

8. Route/Tunnel Configuration after MN config’s address/prefix via AR1 MN1AR1 AR1tunnel MN1on-link AR1 AR2 MN1

9. MN1 Route/Tunnel Configuration After MN moves to AR2 MN1AR2 AR2tunnel AR1 AR2 MN1on-link

10. Additional Considerations • Works with IPv4 as well as IPv6 (IPv6 has some advantages) • Supports DHCPv6 prefix delegation (delegated prefixes move along with the MN) • tunnels from MAPs to ARs can be unidirectional • Explicit messaging between MAPs and ARs might be better than implicit route add/delete based on DHCP messages – being worked in IETF NETLMM wg

11. Additional Considerations (cont’d) • With multiple ARs on the link, ambiguous as to which AR is selected in MAP forwarding tables – MN can assert AR selection by sending L3 multicast DHCP Solicit/Request to unicast L2 address of a specific AR • global addressing goes through MAPs, but efficient local communications can be supported using IPv6 ULAs (could result in dropped calls) • Since MNs can move freely between access networks, Redirects could cause dropped calls. ARs on NETLMM links should therefore not send redirects.

12. Issues • can DHCP Confirm be used to test whether a delegated prefix is appropriate for the new link. If not, why not? • with all global addresses/prefixes delegated by DHCP server, no need for DAD on NETLMM links? • link-local addresses can also be registered with DHCP server. Again, no need for DAD?

13. MANET Autoconfiguration using DHCP fred.l.templin@boeing.com

14. Provide Network(s) MANET Gateways (MGs) MANETs MANET Routers MANET Autoconf Problem Space

15. MANET Routing Alternatives • MANET routing as a L2 mechanism w/no L2 multicast flooding – MANET looks like an NBMA link that connects routers/gateways (no gateway discovery; not considered further) • MANET routing as a L2 mechanism w/L2 multicast flooding - MANET looks like a bridged campus LAN (no special MANET Autoconf extensions needed) • MANET routing as a L3 mechanism w/no L3 multicast flooding – MANET looks like multiple links w/no multicast (no gateway discovery; not considered further) • MANET routing as a L3 mechanism w/L3 multicast flooding – MANET looks like multiple links w/MANET-wide (site-scoped) multicast (subject of this proposal)

16. MANET Autoconf Goals • MANET Routers (MRs) must be able to discover MANET Gateways (MGs) even if they are multiple L3 hops away • MRs must be able to obtain global IP address/prefix delegations • support for multiple MGs • support for intra- and inter-MANET mobility for MRs • Support for both IPv6 and IPv4

17. MANET Autoconf Using DHCP • Let each MR and MG configure a MANET Local Address (MLA) for routing protocol operation; local communications (for IPv6, likely to be RFC4193 ULAs) • Let each MR be a DHCP client • Let each MG be a DHCP Relay/Server • Let there be a means for MRs and MGs to send “Extended” RS, RA and DHCP messages

18. Extended RS, RA and DHCP Msgs • normal RS/RA/DHCP message configured per RFC2461, RFC3315, RFC3633 • message encapsulated in outer IP header with: • src = MLA of sender • dst = Site-scoped multicast, or MLA of target • Hop Limit = small integer value (e.g., 2, 5, 10) • message “tunneled” to one or more recipients

19. Extended RS, RA and DHCP Msgs Normal RS/RA/DHCP Message Message src=LL/Unspec dst=All_*_Multicast Hop Limit = 255 Inner IP header src=MLA(sender) dst=Site-scope Multicast or MLA(target) Hop Limit = 2,5,10,etc Outer IP header

20. Model of Operation • MR discovers MGs via Extended RAs (ERAs) (MR sends ERSs if necessary) • If ERAs contain prefix options, MR can configure addresses using RFC2462, then “register” them with the network by sending Extended DHCP Solicit/Request with IP address options • If ERAs contain no prefix options, or if prefix delegation is desired, MR requests prefixes by sending Extended DHCP Solicit/Request per RFC3633 • MG decapsulates the Extended DHCP Solicit/Request and relays it to a local DHCP server or a server in the provider network

21. Model of Operation (cont’d) • DHCP server sends reply to MR which is intercepted by MG; MG performs a “route add” and “create tunnel” for MR • MR receives the DHCP reply and performs a “route add” and “create tunnel” for MG • Now, packets from the Internet destined to MR are directed to MG which tunnels them to MR, and packets from MR destined to the Internet are tunneled to MG • If MR moves to new MG, it sends an Extended DHCP Confirm which causes MGs to update their IP forwarding tables

22. Route/Tunnel Configuration after MR1 conf’s address/prefix via MG1 MG2 MG1 MR1 defaultMLA(MG1) MLA(MG1)tunnel MR1MLA(MR1) MLA(MR1)tunnel

23. Route/Tunnel Configuration after MR1 moves within MANET MG2 MG1 MR1 defaultMLA(MG1) MLA(MG1)tunnel MR1MLA(MR1) MLA(MR1)tunnel

24. Route/Tunnel Configuration after move to MG2 in same MANET MG2 MR1MLA(MR1) MLA(MR1)tunnel MR1 defaultMLA(MG2) MLA(MG2)tunnel MG1

25. Route/Tunnel Configuration after move to MG3 in new MANET MG2 MG2, MG3 connected to same provider MG1 MG3 MR1MLA(MR1) MLA(MR1)tunnel MR1 defaultMLA(MG3) MLA(MG3)tunnel

26. Additional Considerations • Compatible with “NETLMM using DHCP” • Works with IPv4 as well as IPv6 (IPv6 has some advantages) • For IPv4, need a new option (“MLA Option”) to inform relay of MR’s MLA for last-hop forwarding purposes • Supports DHCPv6 prefix delegation (delegated prefixes move along with the MN) • tunnels from MGs to MRs are bi-directional (but, tunneling from MR to MG can be omitted if “default” is propagated through MANET)