[DNA] Re: [DNA-BOF] [Announce] DNA in IPv6 Goals I-D

[Alper Yegin <alper@docomolabs-usa.com>]

Hello JinHyeock, Greg,

Thanks for putting together this informative document. Here is my review
comments:

[1]

   It is important to note that DNA does not incorporate actual IP
   configuration. For example, with respect to DHCP, it's the detection
   system's task to get the confirmation that a node needs to perform
   DHCP. It's not DNA's job to actually retrieve the information from a
   DHCP server.

It is good that the draft distinguishes between the detection and
configuration. I think we should also note that sometimes the action we take
for detection might also overlap with the configuration actions. For
example, a router solicitation sent to detect availability of the current
router would also deliver the router advertisement from the (potentially)
new router, which is needed for the new IPv6 address configuration.

I suppose the following text hints this fact:

   While Detecting Network Attachment does not prescribe any particular
   mechanisms for configuration, it aims to support each requirement by
   determining if this configuration is required and providing necessary
   information, for example on-link prefixes.

[2] 

2. The Tasks of Network Attachment Detection
                   
   Detecting Network Attachment aims to determine whether a host's
   existing IP configuration is valid by checking L3 link change, upon
   establishing a new link-layer connection.

I think it'd be useful to describe why a link change does not always imply
an IP subnet change, and how come network-layer configurations can stay the
same despite a change in link-layer connectivity (e.g., several APs
connected to the same IP subnet).

[3] 

   Automatic configuration mechanisms in IPv6 allow the host to:
   
   1) Choose a suitable default router
   2) Configure per-link information such as address reachability times,
      maximum transfer units &etc.
   3) Configure link-local and global unicast addresses.
   4) Join multicast groups
   5) Determine authentication state for off-link communications.

I'm not sure what #5 is referring to.

[4] 

   To check its IP layer connectivity and gather the necessary information,
   a node may use any of the following features:
                   
   1) Neighbor Solicitation/Neighbor Advertisement (NS/NA) exchange
   2) Router Solicitation/Router Advertisement (RS/RA) exchange
   3) Link-layer (L2) Information

It's a subtle detail, but the #3 could really read "Information provided by
the link-layer". Sometimes the link-layer provides a network-layer
information, such as the IP address when the link is PPP.

[5] 

   While this is sometimes the case, not all IP stacks will be aware of
   this signaling at the network-layer, nor will indications from link-
   layers necessarily always be accurate.

More so than accuracy, I'd say the problem is "sufficiency". When the IEEE
802.11 mac says it has attached to SSID "linksys" it's 100% accurate, but
not sufficient to make a determination regarding IP configuration change.

[6] 

   On the other hand, a host can't be sure that its current default
   router is reachable, even if it can communicate with the router which
   has the same address as its current router address. That router may
   be a different one, which, though highly unlikely, happens to have
   the same link-local address as its current default router.

It's not really highly unlikely, considering that there is at least one
implementation that configures the same MAC address on each one of the
physical interfaces (hence the same link-local address).

[7] 
 
   DNA schemes SHOULD incorporate the solutions developed in IETF SEND
   Working Group if available, where assessment indicates such
   procedures are required.

I think we mean "DNA schemes should work with both ND and SEND".

Cheers,

Alper