concerns about designating the mag as a default router n.
Skip this Video
Loading SlideShow in 5 Seconds..
Concerns about designating the MAG as a Default Router PowerPoint Presentation
Download Presentation
Concerns about designating the MAG as a Default Router

Concerns about designating the MAG as a Default Router

7 Views Download Presentation
Download Presentation

Concerns about designating the MAG as a Default Router

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Concerns about designating the MAG as a Default Router James Kempf NETLMM Interim Sept. 27, 2006

  2. Concerns • In practice, “link local” means “subnet local” • In general, link local addresses cannot be assumed unique across the NETLMM domain

  3. 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?

  4. “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)

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

  6. 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

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

  8. 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?

  9. 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

  10. 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

  11. 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

  12. Conclusion • Are there any specific use cases why the MAG must have routing functionality? • Are there any problems with the MAG being a bridge?

  13. 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