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

Reply via email to