Re: [DNA] DNAv6 Review from Mobopts

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Wes

Thanks for your kind and prompt reply. Kindly see my in-line comments.

> > Our basic assumption was that a prefix can't be assigned to more than
> > one link at the same time. The > above example constitutes 'multi-link
> > subnet'. Is such a configuration legitimate in current standard?
>
> Not only is it completely legitimate to use "multi-link subnet", it's
> actually the common case.

In Sec 2.1 of RFC 3513, it's written that

   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.

from which, we assumed that 'multi-link subnet' is not legitimate,
while unfortunately it may be the case in some circumstances.

> Cable MSO's are planning on deploying 10
> million+ subscribers on a "multi-link subnet" for IPv6.  This means that
> entire neighborhoods of homes will be on the same "multi-link subnet".
> I presume that you want to target DNA for wireless access points for
> home routers.  Unfortunately, the majority of homes will eventually be
> on "multi-link subnets" which are geographically co-located.  Therefore,
> DNAv6 in its current form will likely malfunction even for the wireless
> access points that you are targeting.

I can't understand why Cable MSO wants to share IPv6 prefixes among
different links. Such a deployment may make sense in limited IPv4
address space but, IMO, not in IPv6 case. For example, in 3GPP and
WiMAX, it's even recommended that one prefix is assigned for one
mobile node. Unless Cable MSO already burnt a bridge and are totally
committed to multi-link subnet, we'd better recommend "DON'T".

Moreover, I don't see much need for DNA when a mobile node moves
between different homes. DNA is to reduce movement detection time to
achiever seamless handoff but, when you visit a house, at least you
should ring a bell and wait for a reply. :-)

> > Moreover, in such a case, I don't know why a common prefix is
> > advertised at all. The prefix can't be > used for SLAAC or on-link
> > determination. Neither A bit nor L bit can be configured for the prefix.
> > So what's the use of advertising the prefix?
>
> On-link determination and SLAAC in "multi-link subnet"'s is a very
> complicated subject.  We've written some Internet drafts to address the
> problem - but the short answer is that it can be done within the
> confines of the existing specifications, but it is rather tricky.

Maybe it can be done but I still don't understand 'why it needs to be
done at all'. My point is that, in a scenario you described above,
there is no need to advertise a common prefix (and confuse DNA
operation) in the first place. You want a mobile node to send all
traffic to its default router, so L-bit is unnecessary. And I assume a
mobile node is supposed to use DHCP, so A-bit is also unnecessary. It
won't serve any purpose to advertise a prefix with neither L-bit nor
A-bit.

> In short, I suggest that the next version of the DNAv6 (if there is one)
> seriously consider "multi-link subnet"s as a possible deployment
> scenario, and that it be specifically designed to work in that case.
> The other option is to have the option to turn off DNAv6 in homes which
> are part of a "multi-link subnet" - but that would limit the usefulness
> of DNAv6.

If multi-link subnet can't be avoided and will be widely used, we
should incorporate the case. But the simplest and cleanest solution
would be to avoid it. I assume the main purpose of multi-link subnet
is to save address space. Taking IPv6 address space size in to
consideration, I wonder whether such a saving is worth introducing
more complexity. In case there is another benefits from multi-link
subnet, kindly let me know.

Thanks for your kind consideration.

Best Regards

JinHyeock