Re: [DNA] DNAv6 Review from Mobopts

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Bernard

Thanks for your kindly pointing this which, I had missed. Though DNAv6
is no longer a top priority in DNA WG, I post a reply to make some
clarification. Since the mail was a little old, I just reply here and
cc the authors.

> Here's my review of the DNA I-D:
>
> One global concern:
> I'm concerned that DNA may not be applicable to all networks.  There
> seems to be some
> implicit assumptions about the networks that must be true - and these
> assumptions are
> not necessarily going to be true on all of the networks that DNA seems
> to be targeting.
> In cases where DNA cannot automatically determine that the host is in
> such a network,
> it should be possible to turn DNA off manually and resort to old-style
> ND.

ok. However, it's not clear how old-style ND performs DNA. As of my
memory, ND won't say much about movement detection.

> Specific concerns:
> 1) What track is this Internet Draft on - Standards?

standard.

> 2) I'm concerned about two major deployment scenarios, each of which is
> likely to affect millions of subscribers
>    off of the same aggregation router:
>    a) The router offers no PIO in the RA - thus, no prefix is available.
> This is currently being
>       discussed as a possible way to prevent poorly implemented host
> stacks which ignore the M and A bits
>       in the RA from doing SLAAC and force them to do DHCPv6 or not get
> online.  Unfortunately, this
>       case breaks DNA as there is no prefix available to identify the
> link.  The "at least one router
>       on a link MUST be configured with one prefix" is a limitation of
> DNA.

DNAv6 won't work with a link without a prefix. Our assumption was that
it was not much trouble to advertise a prefix for DNA purpose. In case
there will be substantial 'a link without a prefix', DNAv6 should be
changed.

>    b) The prefix for a neighborhood is the same for all access points in
> the neighborhood.  This can happen
>       if home users are off of bridge modems and they are all bridging
> the same prefix (which is defined
>       on a bundle interface of the aggregation router.  This is done to
> conserve address space and simplify
>       network configuration by MSO's.  Unfortunately, this means that
> DNA will detect every AP in the neighborhood
>       as the same link.  Even worse, when DNA causes the node not to do
> DHCPv6 again, the aggregation router
>       which understands which home corresponds to which addresses,
> causes source verify to reject traffic
>       from the roaming laptop.  What should happen is that the node
> should try to do DHCPv6 again when it roams
>       even when the prefix is the same - this doesn't work in DNA.

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?

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?

> 3) The routers being able to advertise a prefix list as complete assumes
> that they know about all the routers on the link.
>    However, one of the routers could be silent for a while, and a router
> may assume that it knows all of the prefixes on
>    the link but may be wrong.

A router can't be silent for a while unless it's out of order. When
solicited, a working router should reply a RA. In case of a
malfunctioning router, DNAv6 may have a trouble. However I point out
even ND would have a similar trouble with a malfunctioning router.

> 4) "Any future non-prefix link identifier MUST be 128 bits long." - Why?

I agree this doesn't have to .

> 5) Are the MAX_RTR_SOLICITATIONS and RTR_SOLICITATION_INTERVAL chosen to
> scale up to 100,000 hosts off of an
>    aggregation router?  What if multiple interfaces startup at the same
> time?  Will there be an RS storm and will
>    the token bucket rate limiting cause RS's to be dropped as described
> in the security considerations case?
>    I suspect that this case may be even more common than you might
> suspect...  You may have to adju
>    UNICAST_RA_INTERVAL and MAX_UNICAST_RA_BURST to deal with interface
> bringups on the aggregation router.

I guess we need more data to make a proper judgment.

> 6) "The router MUST pick the smallest prefix of all the prefixes
> configured on the routers on the link as the
>     common prefix."  What if there are 2 smallest prefixes?

I don't understand. How can there be TWO smallest prefixes?
Mathematically natural number forms a well-ordered set.

As I wrote above, this mail is just to make clarification, not to
resuscitate DNAv6.

Nowadays DNA top priority seems to move simple solution ASAP. ok for
me. It's sad to see DNA stalled for a long while. I'll go over simple
DNA draft and post comments in a few days.

Thanks for your kind consideration.

Best Regards

JinHyeock