Concerns about designating the MAG as a Default Router

James Kempf

NETLMM Interim

Sept. 27, 2006

Concerns

• In practice, “link local” means “subnet local”

• In general, link local addresses cannot be assumed unique across the NETLMM domain

Shared Links Only

• Unique global prefix per mobile node means global address are unique on the link

• Concern confined to links in which the last hop is a shared link (i.e. Ethernet like)

• Pt. to Pt. links will have only two nodes, MN and last hop router, so no problem

• NBMA links will route through default router so default router can control link local routing, so no problem here either– Am I missing anything here?

“Link local” means “subnet local”

• Global address uniqueness is confirmed through link local multicast reachability (RFC 2461)

• For DAD, a node multicasts NS to confirm global address uniqueness to a link local Solicited_Node_Multicast address

• Establishes a correspondence between link local multicast reachability and global address uniqueness (and therefore reachability)

Application Assumptions

• Applications may assume global reachability implies link local reachability

• Example:– Application uses NS for address resolution to establish link local

address reachability of a corresponding global address on a single NETLMM link

• Even though prefixes are different for each mobile node, applications may exchange information that allows this kind of deduction

– Mobile node moves to a new NETLMM link– Global address is still reachable and hasn’t changed but link

local address is no longer reachable• Normal Ethernet links are kind of the opposite

– Most nodes won’t change their link local address – They may change their global address (e.g. RFC 3041 address

privacy)

Nonuniqueness of Link Local Addresses

• Link local addresses must be confirmed for uniqueness using DAD too.

• A node in a NETLMM network will DAD a link local address on its initial link– Change in default router (i.e. MAG) by moving to a

new link means node must redo DAD to ensure link local address uniqueness

– But nodes will redo DAD only if a change in subnet occurs (e.g. “link local” means “subnet local”)

– Redoing DAD if subnet doesn’t change is not default node behavior even under DNA

Solution 1

• Forward link local multicast NS for DAD to all MAGs in NETLMM domain– If conflict, MAG encapsulates SEND secured

NA response to sending router

• Multilink subnet danger

• Let’s not go there

Solution 2

• Require (i.e. “MUST” implement and “MUST” deploy) SEND for link local addresses

• SEND addresses are statistically unique cryptographiclly verifable (SUCV) identifiers

• Extremely low probability of collision if nodes’ random number generator is good

• How to eliminate residual probability of collision? Is it even necessary?

Alternative

• The MAG is an IP level (*not* link level) bridge– MAG routes same IP prefix between its tunnel interface to LMA

and its wireless interface to the mobile node– MAG may have a nontunnel interface towards the Internet on

which it behaves like a standard IP router– IP bridge allows bridging between two different link types

• No loops possible since MAG is by definition a last hop device

• The link between the MAG and the mobile node is point to point

• Last hop router is the LMA• Existence proof: GPRS

– SGSN is a bridge as far as GPRS traffic to/from mobile node is concerned

Simplified Multicast Handling

• MLD REPORT sent to LMA

• No need for any additional processing by the network or mobile node when the mobile node moves to a new MAG– LMA is last hop router and doesn’t change

• Multicast traffic is routed through the tunnel overlay from the LMA to MAG

Implementation Possibilities

• Using a Layer 2 tunnel between the mobile node and MAG confines any link local multicast to the MAG and mobile node– Virtual point to point link– Only two nodes on the link (mobile node and LMA)– No possibility of link local address collision except

with LMA

• Mobile node is on a point to point link with the LMA– Layer 2 tunnel to MAG– IP tunnel from MAG to LMA

Conclusion

• Are there any specific use cases why the MAG must have routing functionality?

• Are there any problems with the MAG being a bridge?

Summary of Conclusions from Discussion

• There are really two separable issues– Whether the last hop between the MAG and the mobile node is a

point to point link or not– Whether the MAG is a router, bridge, or could be either

• Last hop must be a point to point link because otherwise ND provides no protection against duplicates for link local addresses across the NETLMM domain– IPv6 nodes that move to a new router don’t by default run ND for

link locals unless their subnet changes• Whether or not the MAG is a router is unclear,

arguments for either or both need to be clarified– Phil takes an action item to investigate– Jari wants to see this discussed in the protocol spec before we

send it to IESG