Subject: [DNA] Flash renumbering and CompleteRA/CPL maintenance

From: Greg Daley <[email-masked]>
Date: Fri, 15 Jul 2005 11:02:28 +1000

Hi,

When discussing changes to the advertised prefix lists with Brett
we determined that there's insufficient guidance in protocol-00
regarding the lifetimes of received Prefixes in the DNA Option,
for nodes arriving after a prefix stops being advertised
on a link.

For the normal case, a prefix which is to stop being advertised
will have a advertised reduced lifetime (down to 0), and then
the prefix can be reassigned after the original valid lifetime
had expired  (decrements in real-time on hosts as per RFC2461).
Hosts which

For nodes arriving after their only knowledge of the
validity of the prefixes comes from their being advertised in
DNA options.  The DNA option doesn't contain explicit lifetime
information.  This (I guess) means that by default DNA options
are assumed to be valid for 1800 seconds (the maximum
MaxRtrAdvInterval :- 3 times the default MaxRtrAdvInterval).

This means that while these prefixes are readvertised in DNAO,
up to the end of the prefix's valid lifetime, they can have
30 minutes extra life beyond the actual lifetime of the prefix
on the link.

This is problematic for example, if the prefixes are delegated using
DHCP, and there is strong demand for prefixes.  This could lead
to reassignment of prefixes to new links immediately after their
validity expires.

In order to limit the exposure of hosts to this issue (believing
a prefix is still on-link when it is not),  the following
measures may be reasonable:

Firstly, a lifetime in a PIO cannot be overridden by a received
DNA Option.

    This means that any host receiving a PIO containing a valid
    lifetime will believe that in preference to subsequently
    received DNAOs.  These valid lifetimes will be decremented in
    real-time (as per RFC2461), leading to a perceived lifetime
    which cannot exceed the lifetime of the prefix on-link.

This doesn't help hosts which never saw the PIO in the first place,
and only has the prefix configured due to DNAO reception.

Secondly, a completeRA received always updates the list of prefixes
on the link, even by removing existing prefixes before the host
would expire them.

    This means that the next RA from another router received after
    the prefix expires will remove the prefix from the CPL on the host.
    This has security implications, but can be secured with SEND.

By using these mechanisms, a prefix which ceases being on-link can only
be kept by hosts as long as no updating RA information arrives.

I've implemented these mechanisms in the released code for dnadaem (host
inference module for DNA).

An alternative would be to contain a minimum lifetime for the objects
in the DNAO,  I think this would be wasteful of space, and could cause
cascades of configuration as a partcular prefix timed out (out of the
set of advertised prefixes in the DNAO).

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 15 Jul 2005 02:58:50 -0700

> for nodes arriving after a prefix stops being advertised

Greg,

I guess I don't understand the problem you are trying to solve.

In my view, the only use of the prefixes in the DNAO is for the host to 
be able to answer the landmark question itself, in the case when the 
router couldn't answer it (because the router had to multicast an RA in 
response to multiple RSes for instance).

In that view, the prefixes in the DNAO would never have any effect on 
the Prefix List which the host maintains; the Prefix List would be 
maintained by the host based on the PIOs that the host receives.

> and only has the prefix configured due to DNAO reception.

Why would the host want to configure the prefix based on only seeing it 
in a DNAO? And if it does, how does the host know whether the A, O, or R 
flags should be associated with those prefixes?

If we need to do that, the only sane thing IMHO, would be to extend DNAO 
to contain the lifetimes  and the flags that are carried in the PIO; 
thus this would be the same size as a PIO.

But as I said, I don't see any need for this, because when the host 
sends an RS it will receive a response from every router, thus it will 
quite quickly receive all the PIOs. The Landmark option and DNAO serves 
as a way to ensure that the host can always detect whether or not it has 
moved to a different link based on the first received RA, which is a 
useful optimization compared to CPL.

   Erik

---

From: Greg Daley <[email-masked]>
Date: Mon, 18 Jul 2005 11:41:42 +1000

Hi Erik,

> maintained by the host based on the PIOs that the host receives.

Actually, the benefits of the DNAO (in fact the CompleteRA generally),
seem to me to be most useful when they are able to be used to
construct the CPL immediately (for example on an unsolicited RA, or
on a Landmark "No" answer).

This means that even rapid subsequent transition to a non-DNA
network (or DNA network) can be identified as link-change, so long
as the existing reception of RA information can be identified as
complete.

While in general, it's possible to construct the Prefix List just
from PIOs (and they contain more information about timers), any single
received CompleteRA (even containing the DNAO) is sufficient to
identify the prefixes on the link for CPL generation, at the time of
the advertisement.    PIOs can be used to update this information,
as they are received.   They won't always be received before the
information is needed though.

> flags should be associated with those prefixes?

Hang on a minute,  I'm not saying that the addresses are to be used for
autoconf.  I'm saying that the prefixes should be able to be used for
Prefix List management (just as CPL uses them).

> thus this would be the same size as a PIO.

That's an option, but as you see, it's certainly not my aim to use
prefixes which haven't been received in PIOs for autoconf.
If the prefixes are only used to identify the link (which I guessed
was the purpose of CompleteRA anyway), it makes sense for them to be
stored as part of the PL.

As an aside (but not to get sidetracked), even if it was necessary to
have lifetime information in the DNAO, a single 16-bit field would
be sufficient to identify the shortest lifetime (less than 1800
seconds) of any of the learned prefixes.   It's clearly not necessary to
bloat the entire DNAO to 16(prefix)+1(plen)+4(lifetime) octets/prefix.

> useful optimization compared to CPL.

Timing is quite important here.  The duration required to receive all of
the prefixes on a link using CPL is RS_TRANSMISSIONS * 4 seconds (where
RS_TRANSMISSIONS >= 1).  If there's a transition off-link within that
period, then the host's notion of the Prefix List is that it is
incomplete.

Using indications of completeness in the received RAs is valuable, since
it doesn't require drawn out delays before allowing transition outside a
link to be known deterministic.

The question is:

Do hosts keep information learned from DNAO?  If they do, how long do
they keep it for?

The measures proposed are aimed at either:

* limiting the effect of changes to this list of prefixes (based on
   better knowledge from routers)

* Allowing PIOs to supercede this information with more accurate timing.

If the answer to the question is actually different (in that hosts
shouldn't keep the DNAO contents), we really have to re-evaluate what
the CompleteRA is for.

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Jul 2005 01:25:56 -0700

> as the existing reception of RA information can be identified as

Now that I understand the problem you are trying to solve ...

The current draft isn't written with this in mind, but it doesn't seem 
hard to extend it to be able to do this as well. (And as I was reading 
your email I came up with the idea that a single DNAO lifetime, which is 
the min of all the valid lifetimes of the includes prefixes, could be 
included; then I saw you had the same idea already expressed in your 
email :-)

I had initially thought that all routers on the link would either be new 
DNA capable routers, or all be old RFC 2461 routers, but then I realized 
that such a constraint is hard if not impossible to enforce (it would at 
least add complications to the protocol). If this was the case though, 
then movement between DNA and non-DNA links would be easy to detect 
since the DNA bit in the RAs would differ. But assuming we want to 
handle a mix of DNA and non-DNA routers on the same link, then the hosts 
need to be able to track the complete prefix list all the time, and the 
landmark option (and DNAO in multicast RAs) merely become an 
optimization for detecting movement with a single RA.

So I agree with you that DNAO can be useful for quickly constructing the 
CPL. Adding the single "minimum valid lifetime" is needed to do this.

    Erik