Re: [DNA] IMPORTANT: Combined DNA Solution draft

[Jari Arkko <jari.arkko@kolumbus.fi>]

I have read the draft (draft-pentland-dna-protocol3-00.txt).
It looks pretty good! I was particularly impressed how well
it describes the overall solution, including address
assignment.

I do have some comments and questions
though. Please see below:

Technical:

>   Frequently, all routers on a link will advertise the same set of
>   prefixes and so this technique will incur no space penalty.  However,
>   on links where routers advertise different sets of prefixes, packets
>   may be larger.  To combat this, two optional mechanisms are defined.
>  
>
 From what I understand, Landmark RAs can actually be
shorter than regular RAs, even if all routers have the
same prefixes. If there's, say, three prefixes, then the
optimized unicast answer can include just the landmark
but not the other options. Or am I missing something?

>   One uses a technique called a "landmark", where the host chooses one
>   of the prefixes as a landmark prefix, and then includes this in the
>   Router Solicitation message in the form of a question "am I still
>   connected to the link which has this prefix?".  The landmark is
>   carried in a new option, called the Landmark Option.
>
>   A second mechanism for reducing packet sizes applies to unsolicited
>   Router Advertisements.  By selecting one prefix on the link to be the
>   "link identifier", and making sure that it is included in every
>   advertisement, it is possible to omit some prefixes.  Such
>   advertisements will not inform a host of all of the prefixes at once,
>   but in general these unsolicited advertisements will not be the first
>   advertisement received on a link.  Inclusion of the link identifier
>   prefix simply ensures that there is overlap between the sets of
>   prefixes advertised by each router on a link and that hosts will thus
>   not incorrectly interpret one of these incomplete RAs as an
>   indication of movement.
>  
>
I have two issues with this. One is that the optionality
should be defined in a stricter way (and as far as I can
see its not done later either, at least not in 6.1.5.1). It
seems obvious to me that if we are touching code in the
routers, we should at the same time make it mandatory
to support the optimized decision mechanism. Then it
can be optional for _hosts to use_. If router support
is optional then we end up in a situation where landmark
request may fail, which consumes time.

Secondly,it is unclear from the above explanations why
we need TWO optional mechanisms instead of just one.
What specifically is the case where one provides better
performance over the other? We don't need either when
complete RAs can be used. We don't need both mechanisms
when doing a solicited RA. What's left? Situations where
the set of prefixes is too long to fit one RA and at the
same time when too many hosts arrive to send unicast
RAs? But wouldn't LinkID be sufficient for that? Or is
this about support of non-DNA hosts? But this might
be fixed by sending landmark prefixes in the usual prefix
list instead of a special option.

>   Yes (Y)
>
>      The Yes (Y) bit, when included in a Landmark Option in a Router
>      Advertisement, indicates that the prefix referred to in the Prefix
>      field of this option is being advertised by one or more routers on
>      the current link.  In a Landmark Option in a Router Solicitation,
>      this bit MUST be set to zero and ignored by receivers.
>  
>
I'm not sure I understand the need for this particular bit.
If the host has sent a Landmark option, wouldn't the router
include this specific prefix in either the regular prefix list
or in the list of other router's prefixes on this link? If so,
the host should be able to determine that it can continue
to have the same prefix as already has.

>   No (N)
>
>      The No (N) bit, when included in a Landmark Option in a Router
>      Advertisement, indicates that the prefix referred to in the Prefix
>      field of this option is not being advertised by any router on the
>      current link.  In a Landmark Option in a Router Solicitation, this
>      bit MUST be set to zero and ignored by receivers.
>  
>
Hmm... maybe I now understand the need for Yes bit.
We need it to distinguish the case between No=1 and
the RA not taking our landmark into consideration at
all.

(I'm wondering though if a No Such Prefix option would
be another way of achieving this. You send a landmark RS
and get a response that contains the router's own prefixes,
other router's prefixes, and the set of restricted prefixes
that the router thinks are not on the link. This could
trivially be the set of landmarks that were requested
but are not on the link. But it could also be a union
of those, or the set of ALL prefixes that are known to not
be on the link...)

>6.1.5.1  Space Optimized Advertisements
>
This seems to cover only the Y=1 case.
What about Y=0? (Oh, now I see that it
comes in later. Maybe add a note to 6.1.5.1
about this.)

>      The prefix MUST be one the host is using for one of its non-link-
>      local IPv6 addresses.
>  
>
Using when, and for what? When the host arrives on this
link, it may not have any non-local traffic. And where
there are multiple prefixes, its quite possible that at
time t1 the host is using one prefix but at time t2 its
using another prefix (e.g., due to RFC 3484 rules).
Or do you mean "use in an address that is currently
configured?" Maybe you could say

   The prefix MUST be one of those that the hosts has
   used to assign a non-link-local address to itself.

Does scope matter?

Maybe you could also add something about the possibility
that the Landmark Prefix needs to change. (And it does,
if the prefix lifetime runs completely out.)

>If the previous state of an address was
>   "Preferred", whether or not the host initiates optimistic Duplicate
>   Address Detection depends on the configurable DNASameLinkDADFlag
>   flag.  A host MUST forgo sending an NS to confirm uniqueness if the
>   value of the DNASameLinkDAD flag is False.  If, however, the
>   DNASameLinkDAD flag is True, the host MUST perform optimistic
>   duplicate address detection on its unicast link local and unicast
>   global addresses to determine address uniqueness.
>
Why do we need to do this? I sense a possibility here
for frequent Link Ups caused by radio coverage issues,
leading to frequent DADding.

>6.2.6.4  Packet Delivery During DNA
>
>   The specification of packet delivery before, during, and immediately
>   after DNA when a change in point of attachment occurs is out of scope
>   for this document.  The details of how packets are delivered depends
>   on the mobility management protocols (if any) available to the host's
>   stack.
>  
>
This text is somewhat confusing. Are you talking about
what IP packets you can send on the link? Right after completion
of DNA you can send and receive anything. Or are you
talking about FMIP-like schemes? Or global mobility
protocols like MIPv6?

Suggestion: don't talk about the latter two at all. Change
text to talk about case 1.

>   such threats, DNAv6 hosts SHOULD deploy RFC 3971 (SEND) secure router
>
Deploy or support? Or maybe just say "may use".

Editorial:

>   RFC 2461 is difficult because of the flexibilities offered to routers
>
flexibility, I think

>   achieve fast RA.  In this memo, an integrated solution is presented.
>
Fast RA?

>1.  Contributors
>
Move at the end.

>2.  Introduction
>
Needs to be expanded to be useful for readers who are
not familiar with the history.

>The protocol
>   handles this quite well during graceful renumbering (when the valid
>
s/quite well//

>   removed and perhaps reassigned to a different link), however, it can
>   also cope with "flash" renumbering and reassignment but not in an
>   optimized fashion.
>  
>
Already in this section it would be useful to understand
whether the issue is non-optimality or if there's some
incorrectness issues as well (such as making a false
positive decision that we are on the same link).

>4.1  What Identifies a Link?
>
>
>4.2  Link Identification
>
Hmm...

>   DNA (D)
>
>      The DNA (D) bit indicates that the router sending the RA is
>      participating in the DNAv6 protocol.  Other routers should include
>      this router in calculating response delay tokens.
>  
>
If I have understood correctly, wouldn't "Fast RA (F)" be
more appropriate name?

>6.1.9  Scheduling Unsolicited Router Advertisements
>
Funny indentation in this section.

--Jari