1 / 12

Multilink Subnets draft-thaler-ipngwg-multilink-subnets-0 1 .txt

Multilink Subnets draft-thaler-ipngwg-multilink-subnets-0 1 .txt. Dave Thaler dthaler@microsoft.com. Interim Meeting Summary. Presented –00 Agreed on concepts, motivations

rae
Download Presentation

Multilink Subnets draft-thaler-ipngwg-multilink-subnets-0 1 .txt

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. Multilink Subnetsdraft-thaler-ipngwg-multilink-subnets-01.txt Dave Thaler dthaler@microsoft.com IETF 51, IPv6 WG

  2. Interim Meeting Summary • Presented –00 • Agreed on concepts, motivations • A “multilink subnet” is when you have an address prefix which spans multiple links, but is routed between them at layer three. • Two models for host view work without changing hosts • Onlink: hosts use NSs, routers send proxy NAs for offlink nodes • Offlink: hosts use default routers, routers send redirects for onlink nodes • Presented several possibilities for router behavior, many open issues IETF 51, IPv6 WG

  3. Router Scenarios Issues • Simple scenarios are simple, complex scenarios are complex • Should the first spec limit itself to simple scenarios? (Complex behavior could take a long time) • Is it complex to tell the difference? • What’s the best way to solve complex scenarios? IETF 51, IPv6 WG

  4. Related questions • How do you handle simultaneous DAD for the same address by nodes on different links? • How do you tell the difference between a duplicate and a node moving to a different link? IETF 51, IPv6 WG

  5. Main changes since -00 • Attempt to classify “simple” vs “complex” scenarios, to evaluate solutions • Class 1 = single multilink subnet router • Class 2 = tree topology • Class 3 = arbitrary topology • Better(?) classification shortly… • Moved discussion of router-router coordination possibilities to appendix • Various wording clarifications IETF 51, IPv6 WG

  6. “Simple” Scenario (Part 1/2) • MLSN router has 0 or 1 (or more?) “proxy” interfaces, and 1 or more “router” interfaces • Same scenario as a NAT • Same scenario as an IGMP/MLD Proxy • Does not run any routing protocol • Does not support “transit” • But does act as an MLD Proxy • Does simple NS/NA proxying IETF 51, IPv6 WG

  7. “Simple” Scenario (Part 2/2) • On proxy interfaces: • Acts like a host with lots of addresses • On router interfaces: • Acts like the (only) default router • If it sees an RA from another router, something is broken so stop acting as router on this interface (either it’s not a simple scenario, or else it was the wrong interface type) • MAY(?): auto-configure which interfaces are proxy vs router, based on hearing other RA’s? IETF 51, IPv6 WG

  8. Some “Simple” Scenarios (1/3) • Single router connecting multiple links in an isolated network • All interfaces are router-mode interfaces MLSN Router R R R IETF 51, IPv6 WG

  9. Some “Simple” Scenarios (2/3) • Multiple MLSN routers on a shared LAN with uplink router(s), with each MLSN router having 1+ internal links • Proxy-mode on shared LAN • Router-mode in private links Router Router MLSN Router MLSN Router MLSN Router (NOT TO SCALE) IETF 51, IPv6 WG

  10. Some “Simple” Scenarios (3/3) • Internal links sharing same prefix as a dialup link Dialup Server MLSN Router IETF 51, IPv6 WG

  11. “Complex” Scenario • MLSN router co-exists with others in an arbitrary topology • Must use some router-router coordination mechanism • Routing protocols or complex proxying rules • Can co-exist with “simple” MLSN routers • Complex box sees simple box as a normal host • Simple box sees complex box as a normal router IETF 51, IPv6 WG

  12. Proposal • Main draft should provide framework for both simple and complex, but only specify behavior of a simple box • Can hopefully get this done quickly • Ask that this be a WG document • Continue work on complex behavior in a separate draft IETF 51, IPv6 WG

More Related