Re: [DNA] Design Team solution 1: Question about DNA Option

[Erik Nordmark <erik.nordmark@sun.com>]

Greg Daley wrote:
> from draft-pentland-dna-protocol-00.txt:
> 
> Section 4.3:
> 
> The learned prefixes in the DNA option are not
> 8 octet aligned, and include prefix lengths.
> 
> Assuming that advertised prefixes are global
> addresses, can't the prefixes be:
> 1) 8 octet aligned and
> 
> 2) 8 octets (64 bits) long
> 
> With no prefix length field.

Since prefixes can be of arbitrary length (0-127 bits) [there is nothing 
that constrains the length for the 000/3 part of the address space, and 
I wouldn't be surprised if over time we relax the /64 recommendation 
either], the only way you can ensure that *all* the prefixes in the DNAO 
are 8 byte aligned is to include 16 bytes for every prefix.
 From an implementation perspective there aren't any benefits to ensure 
that some prefixes are 8 byte aligned, since you need to write code to 
handle the unaligned cases anyway.

Up leveling, I'd expect that in the wast majority of IPv6 links, all the 
routers would advertise the same set of prefixes. While RFC 2461 in its 
generality allows for different set of prefixes being advertised by 
different routers, I see no operational use for this when running a 
stable network.
When all routers advertise the same set of prefixes, DNA would never 
need to send a DNAO option. Thus spending a lot of complexity on trying 
to optimize the DNAO option layout doesn't make much sense to me.

> Also, if there is a requested landmark prefix, could it not appear
> in the DNA option, even if the option is does not provide complete RA?
> The minimum NACK for an unknown landmark would then be 8 octets
> (no prefixes in the list), on top of the existing RA.

Since in the wast majority of cases there wouldn't be a DNAO, I don't 
see the benefits of overloading the DNAO with the landmark 
question/answer parts.

 > The solicited RAs then already have space for either a landmark or
 > a completeRA (DNA) Option.  Each of the specifications will have
 > wasted space, which can be put to use for other purposes.

What is the wasted space and in which case?
We have 3 cases:
1. LO with "yes" answer (just the RA header + LO).
2. LO with "no" answer (RA+LO+misc options+PIOs) ["misc" being MTU etc]
3. Multicast RA (periodic and solicited): RA+misc options+PIOs and DNAO 
if there are any learned prefixes

I don't see much wasted space in either one of them.

 > It's actually not one bit of information either.
 >
 > The fact that a host knows all the number of prefixes but can't fit

s/host/router/>>>

 > them in an RA can be used to compose a complete prefix list which is
 > provably (with SEND) complete.  At least the MN can stop hunting for new
 > prefixes if in the responses from two or more routers, it can see that
 > a conjoined (and complete) set of prefixes is available.

The DT discussed whether a count of prefixes was useful when not all 
advertised and learned prefixes fit in one RA, but came to the 
conclusion that due to the prefix not being static, it actually doesn't 
help. The routers might at any time be reconfigured to advertise an 
additional prefix, one less prefix, or replace one prefix with another.
Combining this with the fact that the host in question plus the N 
routers on the link form a distributed system, and there is no definable 
order of the events in a distributed system (see "Time, clocks, and the 
ordering of events in a distributed system" by Leslie Lamport), the DT 
couldn't come up with any host processing rules that would use a count 
of prefixes that actually worked.



 > I don't like the yes/no either.

Did you have some technical comments, our should we switch to discussing 
our personal tastes and distastes :-)

 > Well, SEND already has better response matching than this
 > using its Nonce Options (which are mandatory for SEND responses).
 >
 > It's also possible to use this without SEND as detailed in:
 >
 > draft-daley-dna-nonce-resp-01.txt
 >
 > Sorry about the self plug, but I think it's a good solution.

But that solves the question of making matching the RA with the RS, 
which isn't a problem we need to solve.
The problem we need to solve with landmark is making sure that the 
answer applies to the question. This problem is solved in the draft by 
repeating the question with the answer. (A technique which is also used 
in the DNS protocol.)

For example, if host H1 and H2 have duplicate addresses, and send the RS 
while being in optimistic DAD mode, then it might be that the RS sent by 
H2 results in a unicast RA being delivered to H1. This is harmless, 
since the host verifies that the question in the LO is indeed the 
question they asked, and if not ignore the answer. And if both hosts 
asked the same landmark question then H1 will happily accept the LO 
answer that was a result of H2 sending an RS.

This never gets things wrong.
A nonce scheme is making a probabilistic argument about the likelihood 
of the two hosts picking the same nonce, hence needs to depend on good 
random number generators. And with a non-zero probability it will end up 
with two hosts picking the same nonce.

Note that using nonces in SEND is a bit different. First of all, to do 
security you need a good random number generator. Second, SeND doesn't 
fail if two hosts by chance pick the same nonce; SeND just needs to make 
  it unlikely that a nonce value gets repeated, since it would allow an 
attacker to replay an old message.

     Erik