Hi Julien,

I don't think there is a problem.

If you use the prefix-per-MN case on a broadcast link, what you get is a
link comprising multiple subnets.  RFC 3513 explicitly allows links with
multiple prefixes:

   Currently IPv6 continues the IPv4 model that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

(This is, BTW, the passage that Dave Thaler cites in
[draft-thaler-intarea-multilink-subnet-issues].)

In the scenario you describe (the one including MNs A, B, and C), you
simply have a link with 3 prefixes.  The unusual, but still legitimate
circumstance in this scenario is that the MNs do not see their
neighbors' prefixes.

Note that a situation where hosts on the same link see different
prefixes may also arise when the link has multiple routers, each router
advertises a different set of prefixes, and no two hosts receive RAs
from the same router due to packet loss.  The hosts will then not be
aware of their neighbors' prefixes.  Certainly, this is unlikely to
happen, but it may happen.

Let me know if I have missed something.

- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/



Julien Laganier wrote:
> 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