[DNA] Comments on the DNA goals draft

[Jari Arkko <jari.arkko@kolumbus.fi>]

Here are some comments on the DNA goals draft. I think
the document looks overall very good! Apologies if some of
the below questions are caused by jet lag:

> 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.

Question: Is this true for all link layers? It was not true for
PPPv4, for instance. It is true for PPPv6, but only for global
addressing, not link-local communications. Is it true for 3GPP
and 3GPP2 networks?

>  Today a link change necessitates an IP configuration change.

I think you mean "... necessitates an IP configuration be
verified or re-ackquired", because you could certainly
move from one link to another and have all your IP parameters
stay the same. Or do I misunderstand the term "link"?

>  Even if an address prefix is valid, an individual address is known to
>  be valid only after the Duplicate Address Detection (DAD) procedure
>  [5] has been completed.

Do you assume that the host knows an L2 change has occurred? If
so, running DAD may be necessary. But if you don't reliably know
that L2 change has occurred, you don't know when you should be
rerunning your DAD.

On the other hand, if the same prefixes  are still valid on
this new link as were on the old L2, how come DAD needs to
be rerun? From a global perspective, if there two L2 instances
use the same IP prefix, a DAD performed on one link should
be visible on the other too, otherwise we can have a
collision.

>  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

What do we assume about the reason why they have the same link-local
address? I can imagine EUI-64 collision as one such reason. However,
if that is the case, the what Bernard recommends for DNAv4 (checking
IP and MAC addresses of the default router) would fail under similar
conditions.

It would be good to be more precise about what failure mode we
are trying address. Is it the manual configuration of two routers
to have the same link local address?

>  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.

You could write this shorter as

  DNA 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.

> G2 When upper-layer protocol sessions are being supported, DNA
>    schemes should detect the identity of an attached link rapidly,
>    with minimal latency.

I would think ULP sessions are supported in all nodes :-)

I think you mean "... sessions are expected to survive link changes, ..."

Anyway, I'm not sure this alone is the one and only reason for having
a rapid process. I also want my portable device to react fast when
I press "On" or "Internet".

> G7 DNA schemes should be compatible with security schemes such as
>    Secure Neighbour Discovery [8] and IPSec [7].

I understand the SEND part. Not sure I understand the IPsec
part (note the small "s"). Do you mean that DNA should work
when IPsec is being used to secure ND? Or when you use IPsec
in general? I sure agree with the latter, but in that case
it should probably say something TLS and bunch of other things
too... perhaps you could clarify what your requirement is.

>  Use of [8] to
>  secure Neighbor Discovery are important in achieving reliable
>  detection of network attachment.

s/are/is/

> Security Considerations

You may want to add something like what Bernard wrote in
his DNAv4 document about not trusting the DNA procedures
to turn on/off your personal firewall based on "recognizing"
your home network. At least if you are not using SEND.

--Jari