Re: [DNA] IMPORTANT: Combined DNA Solution draft

[Brett Pentland <brett.pentland@eng.monash.edu.au>]

Hi Jari,

Thanks for your comments and the detailed review.  I'll respond
in-line.

Brett.

Jari Arkko wrote:
> 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?

Yes, that's true.  This is one of the techniques offered below that can
reduce the RA size.

>>   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.

You may be right, but I'm not sure.  The intent here is that the base
means for determining link change is the complete RA.  If both
the host and router support landmarks, then the smaller RA
is possible.  I can't think of a good reason why a router would
not want to support landmarks, but I don't think whether it does
or doesn't breaks anything.

   - If the RS has a landmark and the router recognizes it
     a short RA is possible.
   - If the RS has a landmark but the router doesn't
     understand it, the landmark is ignored and a complete RA is sent
     that the host can use to make an immediate decision.
   - If the RS has no landmark, then the router sends a
     complete RA that the host can again make use of immediately.

A reason for a host choosing not to include a landmark, is that
it may not wish to expose where it has been previously.

> 
> 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.

If it is unclear then clearly the text needs some tweaking :)
They are not meant to be compared with one another because
they apply in different situations.  Landmarks are useful
for the RS/unicast RA exchange.  LinkID allows unsolicited
RAs to be shortened.

In this draft, hosts have no notion of the LinkID.  They are
looking for RAs that have no prefixes in common with those that
they have already seen as an indication that they have moved to
a new link.  The LinkID is just a way to make sure that there
will always be overlap between the sets of prefixes in RAs that
are advertised on a link.

> 
>>   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.

Yes.  That was the idea.

> (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...)

Are you talking about being able to send a multicast RA that
can NACK multiple Landmarks at once?  We did discuss this
idea a bit (multiple no-flagged landmark options) but in the
end thought that it was a bit complex and that for multicast
it was simpler to send a Complete RA that gives the necessary
information regardless of the question.

> 
>> 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.)

OK.  Will do.

> 
>>      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.

Yes, that sounds a lot clearer.

> 
> Does scope matter?

Well, it must be greater than link-scope.  Beyond that, I guess
that uniqueness is more important than scope.  A ULA prefix,
for example, should be fine even though it has local scope.
Perhaps some explanatory text to this effect?  How about:

    The prefix MUST be one of those that the host has
    used to assign a non-link-local address to itself.
    While any scope greater than link-scope is acceptable,
    the prefix SHOULD be one that is unlikely to be advertised
    on another link.  Globally Aggregatable Unicast Address
    prefixes and Unique Local Address prefixes are examples
    of this.

> 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.)

OK.  How about an addition to the first point in that section?

From:

       The prefix MUST have a non-zero valid lifetime.

To:

       The prefix MUST have a non-zero valid lifetime.  If the
       valid lifetime of a previously selected Landmark Prefix
       expires, a new Landmark Prefix MUST be selected.
> 
>> 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.

Well, when connecting to a network, a host doesn't necessarily know how
long it was disconnected for, and so probably should check that its
address is still unique on the link.  Like you say this could lead a lot
of DADing, so we thought that there should be a knob to allow this
behaviour to be turned off.  Note that the default is for it
to be turned off.

> 
>> 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.

I think this was getting at the latter two.  With case 1 were you
referring to the time between sending an RS and receiving an RA?
I don't think we have discussed that at all, so it's a good one to
discuss.  Should packets from upper layers be blocked until
completion of DNA (and possible address reconfiguration)?
I'm not sure about that one.  On one hand we don't want to lose
packets if we have actually moved, but on the other, we probably
don't want to sit around waiting for an RA when we're really still
on the same link (maybe there's only one router and the first RA
got lost).  I'd probably lean towards blocking.  Does anyone have
any suggestions?

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

Probably support, I think.  DNA is suggesting that hosts abandon
existing configuration when movement takes place, so that makes
it a bigger target for faked advertisements.

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

OK.

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

How about "receive an RA quickly"?

> 
>> 1.  Contributors
>>
> Move at the end.

There was a mix-up with the authorship details.  I have posted an -01
draft, but it hasn't shown up in the repo yet.

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

OK, I'll see what I can come up with.

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

OK.

>>   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).

OK, I'll have a think about that.


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

:)  How about 4.1 becoming the first paragraph of 4.2?

> 
>>   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?

Yes.

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

You're right.  I'll fix it.
> 
> --Jari
> 

Thanks again.
Brett.