[DNA] Scope of solutions discussion document

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

Hi DNA WG,

Does anyone who's had a chance to look at the DT solutions discussion
document have an opinion on the coverage of the topic?

http://www.ietf.org/internet-drafts/draft-dnadt-dna-discussion-00.txt

I was hoping to find out if there are any large areas (or small ones)
that we did not consider but should have.

For those that want the short version:

The basic asssumptions that we made were that:
- hints from layer 2 would be available to trigger router solicitations
- link-scope multicast packets are able to reach all routers on a link
   with a loss probability < 1.
- hosts with interfaces that can connect to more than one link at once
   are able to distinguish packets from those different links.

It was felt that the information required for configuration change, if
required is carried in an RA, so in genereal an RS/RA exchange will be
needed and it is possible that this is all that will be needed.

There are then two parts to DNA:
1. Crafting the information in the RS/RA so that a host can accurately
    determine whether its existing IP configuration is valid, and if not,
    have enough information to start reconfiguration.
2. Getting an RA as fast as possible.

A number of techniques are discussed to address each of these parts.

1. a) Adding explicit link identfiers to RAs - both the random kind
       and those that are, or are based on prefixes in use on the link.

    b) Including all prefixes in use on a link into RAs, with appropriate
       flags, etc. to ensure that prefixes that are not explicitly
       configured on a router are not used as though they are.

    c) Getting hosts to include some feature of a link (prefix, router
       address, etc) in the RS and allowing routers to include flags in
       the RA that indicate whether this feature is present on the link.

    d) Getting hosts to include their current default router address in
       the RS and requiring that that router respond immediately if
       present.

2. a) Allowing link access devices (like APs) to cache RAs and deliver
       them as soon as they detect a host connecting to the link.

    b) Allowing one of the routers on a link to respond immediately to
       RSs.

    c) Allowing the routers on a link to negotiate amongst themselves an
       ordering for responding to RSs, and having them respond
       sequentially at fixed intervals starting from no delay.

    d) Allowing routers to respond sequentially as in c) but based on
       some function of the addresses of the other routers and some
       feature of the RS.

    e) Allowing routers to respond to RSs with small randomised slotted
       delays that are based on the number of other routers detected on
       the link.

The document discusses some of the pros and cons of these techniques
as well as dealing with routers that behave as per RFC2461, putting
the pieces together and some discussion of security concerns.

There is also an assumption that DNA is complete when the host has
decided whether its current IP configuration is likely to be valid
or not (link change has occured or not).  It should then have enough
information to go on with SAA or to initiate DHCP, and possibly go on
with other authentication required to reach the global Internet, if
necessary.

All comments appreciated.
Brett.