Thanks for your input, Dave. That's the input I was searching for. Best,
--julien On Tuesday 08 August 2006 22:13, Dave Thaler wrote: > If I understand the picture at bottom, this is fine. > That is, there can be multiple subnet prefixes per link, > and different hosts may be in different subsets of the > set of subnet prefixes. All of this is fine in the IP > addressing model. > > Section 2.1 of the [draft-thaler-intarea-multilink-subnet-issues] > draft acknowledges this: > > In December 1995, the original IP Version 6 Addressing > Architecture [RFC1884] was published, stating: "IPv6 continues the > IPv4 model that a subnet is associated with one link. Multiple > subnets may be assigned to the same link." > > Thus it explicitly acknowledges that the current IPv4 model has > been that a subnet is associated with one link, and that IPv6 does > not change this model. Furthermore, a subnet is sometimes > considered to be only a subset of a link, when multiple subnets are > assigned to the same link. > > -Dave > > > -----Original Message----- > > From: Julien Laganier [mailto:[EMAIL PROTECTED] > > Sent: Monday, August 07, 2006 6:21 AM > > To: Dave Thaler; INT Area > > Cc: James Kempf; NetLMM WG > > Subject: IPv6 addressing model, per-MN subnet prefix, and > > broadcast > > domain > > > Hi Dave, and other folks knowledgeable about IPv6 addressing > > model, > > > > [EMAIL PROTECTED] CCed, please reply only to [EMAIL PROTECTED] > > > > While working on the issues of which addressing model to use in > > NetLMM, I think I got confused with issues involved the IPv6 > > addressing model (or its assumptions.) > > > > I would therefore like to ask you if a potential NetLMM > > addressing model (per-MN subnet prefix [RFC3314]) would, in some > > situations, conflict with the IP addressing model. > > > > Background > > ---------- > > > > Dave's draft on issues involved with multilink subnets > > [draft-thaler-intarea-multilink-subnet-issues] list some > > assumptions of the IP addressing model, but there might be other > > that are not specific to multilink subnets. I'd therefore like to > > ask you about possible conflicts between IPv6 and RFC3314 > > addressing model. > > > > We are considering the situation of mobile nodes (MNs) attached > > to a NetLMM domain. The NetLMM domain span multiple access links, > > each served by a given access router (AR). A MN attaches to one > > link, and hence to one AR. > > > > ( NetLMM domain ) > > / | | | \ > > AR AR AR AR AR > > / \ \ / \ \ > > MN MN MN MN MN MN > > > > If all of the MNs in the domain uses a common subnet prefix we > > obviously end-up with a multilink subnet, which is problematic as > > described in Dave's draft. Now a simple way to avoid multilink > > subnet issues is to use a per-MN subnet prefix, as in the IETF > > recommendation to 3GPP [RFC3314]. That way, each of the MN moves > > has a different prefix and hence none of the prefix spans more > > than one link, thus avoiding multilink subnet issues. > > > > Issue > > ----- > > > > Such model has however raised a question, which is orthogonal to > > multi-link subnets issues. RFC3314 was proposed for use in a > > scenario where the link between the MN and its AR is > > point-to-point. Now if we consider a broadcast/multicast capable > > link-layer technology such as Ethernet, then we would have a > > situation in which, on a given link, the broadcast domain and > > hence the link-local scope are larger than the any of the per-MN > > subnet prefixes scope (as illustrated below when 3 MNs A, B and C > > are connected to one such link served by one AR R). > > > > A subnet prefix scope: -R-------A------------------ > > > > B subnet prefix scope: -R---------------B---------- > > > > C subnet prefix scope: -R------------------------C- > > > > link-local scope: -R-------A-------B--------C- > > > > L2 broadcast scope: -R-------A-------B--------C- > > > > Do you think that this situation (i.e. link-local scope larger > > than subnet prefix scope) would conflict with the IPv6 addressing > > model, or any of its assumptions? > > > > Many thanks in advance. Best regards, > > > > --julien _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
