[DNA] DNA Goals response

["Bound, Jim" <jim.bound@hp.com>]

Greg/Jinchoi,

Except for some intro section and section 4 this entire document does
not represent goals but analysis.  I think they should be two different
docs and two different thread debates. Comments to the point in line.  I
am less concerned in this response with the correctness of statements
but more about the layout of the goals document and what I think we need
a current analysis document both of which require different discussions
and thoughts.

> Abstract
> 
>    At the time a host establishes a new link-layer 
> connection, it may or
>    may not have a valid IP configuration for Internet 
> connectivity.  The
>    host may check for link change, i.e.  determine whether a 
> link change
>    has occurred, and then, based on the result, it can automatically
>    decide whether its IP configuration is still valid or not.  While
>    checking for link change, the host may also collect necessary
>    information to initiate a new IP configuration for the 
> case that the
>    IP subnet has changed.  In this memo, this procedure is called
> 
> 
>    Detecting Network Attachment (DNA).
> 
>    Rapid attachment detection is required when a host has 
> on-going data
>    traffic.  Current DNA schemes are inadequate to support real-time
>    applications.  The existing procedures for advertising network
>    information incur reception delays and do not provide enough
>    information to properly determine the identity of links.  For
>    to-be-defined, efficient DNA schemes, a way to correctly 
> represent a
>    link change, a complete and consistent procedure for network
>    information advertisement and a rapid delivery of the 
> advertisements
>    will be necessary.

I would just keep the first paragraph for the abstract.

> 
> 
> 1.  Introduction
> 
>    When a host has established a new link-layer connection, 
> it can send
>    and receive some IP packets at the link, particularly 
> those used for
>    configuration.  On the other hand, the host has full Internet
>    connectivity only when it is able to exchange packets with 
> arbitrary
>    destinations.
> 
>    When a link-layer connection is established or re-established, the
>    host doesn't know whether its existing IP configuration is still
>    valid for Internet connectivity.  A subnet change might 
> have occurred
>    when the host changed its attachment point.
> 
>    In practice, the host doesn't know which of its addresses are valid
>    on the newly attached link.  A host knows neither if its existing
>    default router is on this link, nor whether its neighbor cache
>    entries are valid.  Correct configuration of each of these 
> components
>    are necessary in order to send packets on and off the link.

Add during "movement to new link" to the above is input.  

> 
>    While other information for IP connectivity (such as DNS server
>    configuration) is also important, obtaining most of such 
> information
>    depends on the determination of correct global addressing and valid
>    default router configuration.

I think the paragraph above needs work.  I could find all this on a link
with no router at all.  
Or clarification.

> 
>    Hence, to determine the need of a further configuration, a 
> host needs
>    to check at least that:
> 
>     1) Whether it knows a (partially) reachable default router.

I don't think this is true unless you add on a new link.

>     2) Whether it possesses a valid IP address.

If it is on a new link it does not and it is on a new link then it hears
the Ras.

The key is the host knowing its link.  Some can argue because link
prefixes cannot be duplicated the chance of not knowing is very slim
because a host can hear all prefixes and it is the case of them changing
very rapidly is the problem.  That is why an option to send all prefixes
is a good thing to pursue.

> 
>    Partial reachability indicates that the host is able to receive
>    packets from the router, but not necessarily vice versa.

Not sure about this.  How is this possible.  If I can get a packet from
an address then I can send to an address? Does this need to be worded
differently or more explanation.  

> 
>    To examine the status of the existing configuration, a 
> host may check
>    whether a 'link change' has occurred.

OK so this is layer 2?  Or layer 3?  Or some API?  Needs to be more
specific or removed.

This is my point we should state the goals not provide a history and
education other than to say link detection needs further investigation.

> 
>    Today a link change necessitates an IP configuration change.
>    Whenever the host detects that it has remained at the same link, it
>    can usually assume its IP configuration is still valid. 

Not usually but always that is what the timers in stateless or stateful
are all about.  Whats up with that statement?

> Otherwise,
>    the existing one is no longer valid and a new configuration must be
>    acquired.  Hence a host only needs to check for link change to
>    examine the validity of its IP configuration.

Correct this is fine and almost enough for the introduction in my view.

> 
>    In the process of checking for link change, a host may collect some
>    of the necessary information for a new IP configuration, 
> for example
>    on-link prefixes.  So, when an IP subnet change has 
> occurred, a host
>    can immediately initiate the process of getting a new IP
>    configuration.  This may reduce handoff delay and minimize 
> signaling.

OK I agree but shouldn't this be part of a solutions section and is this
a goal?

> 
>    Rapid attachment detection is required for a device that changes
>    subnet while having on-going sessions.  This may be the case if a
>    host is connected intermittently, is a mobile node, or has urgent
>    data to transmit upon attachment to a link.

This is a goal yes.

> 
>    The process by which a host collects the appropriate information,
>    detects the identity of its currently attached link, and ascertains
>    the validity of its IP configuration, is called Detecting Network
>    Attachment (DNA).

This is a goal yes.

> 
>    It is important to note that DNA process does not include 
> the actual
>    IP configuration procedure.  For example, with respect to DHCP, the
>    DNA process may determine that the host needs to get some
>    configuration information from a DHCP server.  However, the process
>    of actually retrieving the information from a DHCP server falls
>    beyond the scope of DNA.

OK this is a non-goal.

> 
> 2.  Detecting Network Attachment in Existing IPv6 Systems
> 
>    When a host changes its attachment point, for efficiency, a host
>    should examine whether its IP configuration is still valid before
>    initiating the process of acquiring a new IP configuration.

OK now we are in the solution space not goals.

> 
>    DNA process aims to examine whether a host's current IP 
> configuration
>    is still valid.  To achieve this goal, DNA process checks 
> whether the
>    host is still at the same link.  Also, DNA process 
> collects necessary
>    information for a new IP configuration.

This is an algorithm suggestion not a goal.

> 
>    For this, the following mechanisms and data are available to hosts:
> 
>     1) Router Solicitation/Router Advertisement (RS/RA) messages
>     2) Neighbor Solicitation/Neighbor Advertisement (NS/NA) messages
>     3) Information provided by the link-layer

Ditto.

> 
>    Currently there is no way to represent the identity of links such
>    that link changes can be detected instantly.  The 
> information in the
>    above messages cannot be used to unambiguously identify links.
>    Section 3 gives the detail.

This is not a goal.  I don't agree with #3 if I know at #3 my link is
changed then RS/RA/NS/NA are all on the new link.

> 
>    Though the set of all the assigned prefixes may be used to 
> represent
>    a link identity, it is difficult for a host to attain and 
> retain all
>    the prefixes with certainty.  Moreover there may be  links without
>    any advertised prefix.

Turn the above into a goal and suggest things to look for in the goals.

> 
>    Hence, to check for link change, as of today, a host must resort to
>    guessing, based on Router Discovery and Neighbor Unreachability
>    Detection (NUD).  A host can examines whether 1) its 
> existing default
>    router is still reachable and 2) its IP addresses are still valid.

I can know I am on a new link from the link layer and physical layer for
WiFi, 3G, etc..Ethernet MACs are new.  The answer could be a new field
in those layers and maybe we should look at that and talk with IEEE?

> 
>    After a network attachment, a host receives new (solicited or
>    unsolicited) RAs and compares them with the previously 
> received ones.
>    It checks whether the information in the new RAs, the prefixes and
>    the router addresses, matches with the stored ones, the 
> configured IP
>    addresses and the default router addresses.

This is solution not a goal.

Ditto on the rest of the section it is not goals.

> 3.1  Wireless link properties
> 
>    1) Unclear boundary
> 
>    Unlike wired environments, what constitutes wireless link 
> is variable
>    in both time and space.  It doesn't have clear boundaries. 
>  This may
>    be illustrated by the fact that a host may contact 
> multiple (802.11)
>    access points at the same time.  Moreover reachability on 
> a wireless
>    link is very volatile, which may make link detection hard.

Any device is aware of which wireless net is attached to and that data
is available so I am unclear the statements above are valid? I also do
not agree link detection is hard.

> 
>    2) Asymmetric reachability
> 
>    In some wireless environments, it may be possible to receive
>    periodically multicast advertisement information without being able
>    to send IP packets to the network.  In these cases, it is
>    insufficient to rely upon reception of unsolicited advertisement
>    information as confirmation of router reachability.

This is old and not the norm.  It also applies to radio more than say
WiFi and current medias.

> 
> 3.2  Inadequacies in RA information
> 
>    Usually a host receives the information necessary for IP
>    configuration from RA messages.  Based on the current 
> definition [4],
>    the information contained in RA messages is inadequate to 
> represent a
>    link change.  RA messages are not designed to represent link
>    identities and have inherent ambiguities.

This has nothing to do with Goals and a podium to present one view.
RA's are not to represent link change so lets make one.
But this is a goals document.

> 
>    1) Link local scope of Router Address
> 
>    Usually a router address is contained in the source 
> address field of
>    RA messages.  That router address is link-local scope and its
>    uniqueness can't be guaranteed out side of a link.
> 
>    So if it happens that two different router interfaces have the same
>    link-local address, a host can't detect that it has moved from one
>    interface to another by checking the router address in RA messages.
> 
>    On the other hand, a host can't be sure that its default router is
>    reachable, even if it can communicate with the router that has the
>    same address as its existing router address.  That router may be a
>    different one, which happens to have the same link-local address as
>    its default router address.

We can require that the router use non-link local addresses with a
prefix and those cannot be duplicated across the links. I am not
advocating that but the above statement is not entirely honest or tells
the whole story and also again not a goal.

> 
>    2) Omission of Prefix Information Option
> 
>    To check the validity of its IP address, a host should examine
>    whether the prefix of its IP address is advertised on the link to
>    which it is currently attached.
> 
>    The host checks whether the prefix of its IP addresses are 
> present in
>    the Prefix Information Option of incoming RA messages.  But an
>    unsolicited RA message can omit some prefixes for convenience, for
>    example to save bandwidth [4].

So we fix that in RA's or add new RA fro mobile nodes.

> 
>    Hence, the host can't be sure that the prefix of its current IP
>    address is not supported on the current link, even though 
> the prefix
>    is not contained in a received RA.
> 
> 3.3  Delays
> 
>    The following issues cause DNA delay that may result in 
> communication
>    disruption.
> 
>    1) Delay for receiving a hint

What type of hint and where is the delay at driver interrupt, IP queue,
upto TCP or UDP in the stack?  This is a bold and not well defended
statement as is at all.

> 
>    For rapid attachment detection, hints can be used to tell 
> a host that
>    a link change might have happened.  This hint itself 
> doesn't confirm
>    a link change, but can be used to initiate the appropriate
>    procedures.

Correct but lets go look at the IEEE properties of each link media first
and be sure.

> 
>    Hints come in various forms, and differ in how they indicate a new
>    attachment.  They can be link-layer indications, the lack 
> of RA from
>    the default router or the receipt of a new RA.  The time taken to
>    receive a hint also varies.
> 
>    As soon as a new link-layer connection has been made, the 
> link-layer
>    may send a link up notification to the IP layer.  A host may
>    interpret a new network attachment as a hint for a possible link
>    change.  With link-layer support, a host can receive a hint almost
>    instantly.

Correct and flush its caches.

> 
>    [9] defines the use of RA Interval Timer expiry for a hint.  A host
>    keeps monitoring periodic RAs and interprets the lack of them as a
>    hint.  It may implement its own policy to determine the number of
>    missing RAs for a hint.  Hence the delay depends on the Router
>    Advertisement interval.
> 
>    Without the schemes such as above, a host must receive a 
> new RA from
>    a new router to detect a possible link change.  The detection time
>    then also depends on the Router advertisement frequency.
> 
>    Periodic RA beaconing transmits packets within an interval varying
>    randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds.
>    Because a network attachment is unrelated to the advertisement time
>    on the new link, the host is expected to arrive on average half way
>    through the interval.  This is approximately 1.75 seconds with [4]
>    advertisement rates.
> 
>    2) Delay for checking current default router Unreachability
> 
>    When a host examines the reachability of the current 
> default router,
>    a certain delay occurs if the current default router is not
>    reachable.
> 
>    Usually it's easier to detect a node's presence than its 
> absence.  A
>    host sends a solicitation message and, upon the receipt of a reply,
>    it can assume that it's there.
> 
>    To be sure that a node is absent, time needs to be taken to ensure
>    that the lack of a reply is not due to another reasons 
> (for example,
>    packet loss, MAC latency, or processing delay).  So it 
> takes time to
>    verify the unreachability of the current router.
> 
>    After a host moves to another link, if it uses NUD for 
> detection, it
>    will take more than 3 seconds to recognize that the 
> current router is
>    no longer reachable [4].

That is configurable.

> 
>    3) Random delay execution for RS/ RA exchange
> 
>    Router Solicitation and Router Advertisement messages are used for
>    Router Discovery.  According to [4], it is sometimes 
> necessary for a
>    host to wait a random amount of time to send an RS and for a router
>    to wait to reply an RA.
> 
>    Before a host sends an initial solicitation, it SHOULD delay the
>    transmission for a random amount of time between 0 and
>    MAX_RTR_SOLICITATION_DELAY (1 second).  Also Router Advertisements
>    sent in response to a Router Solicitation MUST be delayed 
> by a random
>    time between 0 and MAX_RA_DELAY_TIME (0.5 seconds).

This is configurable.

> 
> 4.  Goals for Detecting Network Attachment
> 
>    DNA solutions should be 1) Precise, 2) Sufficiently fast and 3) Of
>    limited signaling.  The solutions should correctly 
> determine whether
>    a link change has occurred.  They also should be sufficiently fast
>    lest there should be service disruption.  They should not flood the
>    link with related signaling.
> 
>    It will be necessary to investigate the usage of available 
> tools, NS/
>    NA messages, RS/RA messages, link-layer hints and other features.
>    This will allow precise description of procedures for efficient DNA
>    Schemes.
> 
> 4.1  Goals list
> 
>    G1 DNA schemes should detect the identity of the currently attached
>       link to ascertain the validity of the existing IP configuration.
>       They should recognize and determine whether a link change has
>       occurred and initiate the process of acquiring a new 
> configuration
>       if necessary.
> 
>    G2 When upper-layer protocol sessions are being supported, DNA
>       schemes should detect the identity of an attached link rapidly,
>       with minimal latency.
> 
>    G3 In the case where a host has not changed a link or subnet, an IP
>       configuration change should not occur.
> 
>    G4 DNA schemes should not cause undue signaling on a link.
> 
>    G5 DNA schemes should make use of existing signaling 
> mechanisms where
>       available.
> 
>    G6 DNA schemes should make use of signaling within the link
>       (particularly link-local scope messages), since communication
>       off-link may not be achievable in the case of a link change.
> 
>    G7 DNA schemes should be compatible with security schemes such as
>       Secure Neighbour Discovery [8] and IPSec [7].
> 
>    G8 A host configured for DNA should not expose itself to additional
>       man in the middle or identity revealing attacks.
> 
>    G9 A host or router configured for DNA should not expose itself or
>       other devices on the link to additional denial of 
> service attacks.
>    G10 The Routers supporting DNA should work appropriately with hosts
>       using unmodified configuration schemes, such as [4] and [6].
> 
>    G11 The Hosts supporting DNA should be able to work with unmodified
>       routers and hosts which do not support DNA schemes.

The above is the list of goals we should be debating not all the upfront
opinions and text.  That is second step after the goals.

Thanks
/jim
>