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

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

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.

Yes this is something that needs more thought.

> Assuming that advertised prefixes are global
> addresses, can't the prefixes be:
> 1) 8 octet aligned and

Probably necessary.

> 2) 8 octets (64 bits) long
> 
> With no prefix length field.
> 
>  From RFC 3513 (S2.5.1):
> 
>    For all unicast addresses, except those that start with binary value
>    000, Interface IDs are required to be 64 bits long and to be
>    constructed in Modified EUI-64 format.

Does this imply that all advertised prefixes MUST be 64 bits long?
If so it would simplify the DNAO considerably.

> This would lead to 6 octets overhead (which is the minimum additional
> cost when you consider the size of prefix lengths).
> One of those octets could indicate the known number of prefixes,
> and the option length could indicate how many prefixes are advertised
> (effectively indicating if the RA is complete or not when the PIOs
> are counted).

The known number of prefixes is something which we had in there and
removed.  The thinking was that if the number didn't match the number of
prefixes in PIOs and the DNAO, then it wasn't really much use, and thus
its function was no greater than a "complete" bit.  That bit could go in
the DNAO, but then the DNAO would need to be included, even when there
were no learned prefixes (ie. when routers all advertise the same set of
prefixes on a given link).  This would then mean that 64 bits were
being included to carry one bit of information.

> This would remove the need to get two bits from the RA header in the
> case of
> 
> 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.
> 
> The DNA option could then be used in both solicitor and receiver.

Yes, I think this could be done.  It would be overloading two separate
functions on the DNAO.  Does it provide some advantage to do this?

As the draft stands, we have two modes of operation and the Landmark
Option is used for one, and the DNA Option for the other.  The preferred
mode is a unicast response.  The host uses a Landmark Option to ask
if a prefix is being advertised on a link, and any router can unicast a
response including a Landmark Option indicating yes or no for that
prefix.  The DNA Option is used in multicast RAs as a fallback position
when a unicast is not possible (due to rate limiting or insufficient
information).  It allows the RA to contain enough information for hosts
to be able to make a decision on their own.  The intention is that this
is a fallback position, however, and that the normal state of affairs
would be a simple "Is prefix X being advertised on this link?" - "Yes,
prefix X is" or "no, prefix X isn't".

Brett.