Transcript PPT Version

Network Localized Mobility
Management using DHCP
[email protected]
NETLMM Problem Space
Global Internet
NETLMM
Domain A
localized
mobility
NETLMM
Domain B
Mobile
Nodes
NETLMM
Domain A
global mobility
(out-of-scope)
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)
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)
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
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
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
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
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.
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?
MANET Autoconfiguration
using DHCP
[email protected]
MANET Autoconf Problem Space
Provide Network(s)
MANET Gateways
(MGs)
MANETs
MANET Routers
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/MANETwide (site-scoped) multicast (subject of this proposal)
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
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
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
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
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
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
Route/Tunnel Configuration after
MR1 conf’s address/prefix via MG1
MG2
MG1
MR1
MR1MLA(MR1)
MLA(MR1)tunnel
defaultMLA(MG1)
MLA(MG1)tunnel
Route/Tunnel Configuration after
MR1 moves within MANET
MG2
MG1
MR1
MR1MLA(MR1)
MLA(MR1)tunnel
defaultMLA(MG1)
MLA(MG1)tunnel
Route/Tunnel Configuration after
move to MG2 in same MANET
MG2
MR1MLA(MR1)
MLA(MR1)tunnel
MR1
MG1
defaultMLA(MG2)
MLA(MG2)tunnel
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
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)