1 / 13

Concerns about designating the MAG as a Default Router

Explore the implications of designating MAG as a default router in NETLMM Interim, focusing on address uniqueness, multicast handling, implementation options, and potential challenges.

juanrodriguez
Download Presentation

Concerns about designating the MAG as a Default Router

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related