network localized mobility management using dhcp
DESCRIPTION
Network Localized Mobility Management using DHCP. [email protected]. Global Internet. NETLMM Domain A. NETLMM Domain A. NETLMM Domain B. Mobile Nodes. localized mobility. NETLMM Problem Space. global mobility (out-of-scope). NETLMM Goals. - PowerPoint PPT PresentationTRANSCRIPT
![Page 2: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/2.jpg)
NETLMM Problem Space
global mobility(out-of-scope)
Global Internet
NETLMMDomain A
NETLMMDomain A
NETLMMDomain B
MobileNodes
localizedmobility
![Page 3: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/3.jpg)
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)
![Page 4: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/4.jpg)
NETLMM Domain
Backhaul Network
Access Networks
Mobile Nodes (MNs)
Mobility AnchorPoint(s) (MAPs)
Access Rtrs (ARs)
![Page 5: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/5.jpg)
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)
![Page 6: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/6.jpg)
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
![Page 7: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/7.jpg)
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
![Page 8: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/8.jpg)
Route/Tunnel Configuration after MN config’s address/prefix via AR1
MN1
AR1
MN1AR1AR1tunnel
MN1on-link
AR2
![Page 9: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/9.jpg)
Route/Tunnel Configuration After MN moves to AR2
MN1
AR1
MN1AR2AR2tunnel
MN1on-linkAR2
![Page 10: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/10.jpg)
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
![Page 11: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/11.jpg)
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.
![Page 12: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/12.jpg)
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?
![Page 14: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/14.jpg)
MANET Autoconf Problem Space
Provide Network(s)
MANETs
MANET Gateways(MGs)
MANET Routers
![Page 15: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/15.jpg)
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)
![Page 16: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/16.jpg)
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
![Page 17: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/17.jpg)
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
![Page 18: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/18.jpg)
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
![Page 19: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/19.jpg)
Extended RS, RA and DHCP Msgs
NormalRS/RA/DHCP
Message
src=LL/Unspecdst=All_*_Multicast
Hop Limit = 255
src=MLA(sender)dst=Site-scope Multicast
or MLA(target)Hop Limit = 2,5,10,etc
Message
Inner IP header
Outer IP header
![Page 20: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/20.jpg)
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
![Page 21: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/21.jpg)
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
![Page 22: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/22.jpg)
Route/Tunnel Configuration after MR1 conf’s address/prefix via MG1
MR1MLA(MR1)MLA(MR1)tunnel
MG1
MR1defaultMLA(MG1)MLA(MG1)tunnel
MG2
![Page 23: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/23.jpg)
Route/Tunnel Configuration after MR1 moves within MANET
MR1MLA(MR1)MLA(MR1)tunnel
MG1
MR1defaultMLA(MG1)MLA(MG1)tunnel
MG2
![Page 24: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/24.jpg)
Route/Tunnel Configuration after move to MG2 in same MANET
MR1MLA(MR1)MLA(MR1)tunnel
MG1
MR1defaultMLA(MG2)MLA(MG2)tunnel
MG2
![Page 25: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/25.jpg)
Route/Tunnel Configuration after move to MG3 in new MANET
MG1
MG2
MR1MLA(MR1)MLA(MR1)tunnel
MR1defaultMLA(MG3)MLA(MG3)tunnel
MG3
MG2, MG3 connectedto same provider
![Page 26: Network Localized Mobility Management using DHCP](https://reader034.vdocument.in/reader034/viewer/2022051622/56814e44550346895dbbbceb/html5/thumbnails/26.jpg)
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)