Link Model Analysis for 802.16 based Networks IETF 67 – San Diego, CA 05-10 November 2006

Goal To analyze the IPv6 link models that can be applied for the 802.16 based networks And recommend preferably one link model for the standardization (but we don’t want separate IPv4 vs IPv6 models for the same IP link) Non-goal: make any statements about choice of CS’s.

Link Models Considered NBMA Link Model (which some call the “IPv6 Shared Prefix Link Model”) Point-to-point Link Model Ethernet like Link Model

NBMA Link Model L3 AR Shared Link L2 BS MAC Conn. Tunnel L1 The AR, Multiple BSs attached to the AR and all MSs attached to these BSs form an IP Link One or more prefixes are assigned to the link doesn’t work between MSs Which means many apps/protocols won’t work without changes

Point-to-point Link Model P2P Link 2 MS1 AR Tunnel MAC Conn. MS3 MS2 P2P Link 1 P2P Link 3 BS Each connection between MS and AR forms a separate IP Link Separate prefix per IP Link means each MS sees a different on-link subnet prefix Everything L3+ works normally within the point-to-point link

Ethernet-Like Link Model MS1 AR1 MS3 MS2 BS2 BS1 AR2 MS4 Bridge Similar to Ethernet Emulates multicast with Bridging

Dormancy Dormancy is orthogonal to the link model The BS knows the dormancy state of the MS The BS can determine when it is appropriate to wake the MS The design team concluded that this is not a factor that influences the choice of model.

Limiting multicast/broadcast traffic There is a desire to limit “unnecessary” multicast (and IPv4 broadcast) traffic, even when not dormant Any multicast traffic applications request is desired (not “unnecessary”) Broadcast and all-hosts-multicast may have unnecessary traffic For specific protocols (like ARP), it is possible to add intelligence to the BS and/or the bridge to do intelligent filtering All other multicast traffic already requires that the MS send explicit IGMP/MLD requests to indicate that it is necessary This includes for IPv6 ND IGMP snooping is already well known (RFC 4541) and widely implemented in switches Summary: IGMP/MLD is periodic, vs DAD is one-time IGMP/MLD works for all apps/protocols, DAD only works for one Recommendation: WG should investigate use of MLD snooping rather than other DAD optimizations for IPv6

Short Summary of IGMP/MLD Snooping Host Switch Router Host IGMP/MLD: hosts explicitly request groups other than the all-hosts-group Switch intercepts IGMP/MLD packets and creates group/port state Switch plays an active role upon topology changes (initiate query on topology change) Sends all multicast traffic on router port Only sends requested traffic on host ports

Documentation/implementation status Already commonly implemented for IPv4 by late 2000 There were interop problems at that time, since the behavior was not specified. IDMR/MAGMA WG began documenting requirements and considerations for both v4/v6 Interop problems were addressed 2001-2003 Finally published as RFC 4541 Summary: mature spec exists, even more mature implementations exist

Model Recommendations Ethernet CS: Ethernet-like model AR IPv6 CS: Point-to-point link model AR needs some method for Unique Prefix Assignment

Current Status WG Document WGLC is over, but not received many comments Please review and comment before the document is sent to IESG

Questions, Comments, Suggestions