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

[JinHyeock Choi <athene@sait.samsung.co.kr>]

Dear Alper 

Thanks for not only helpful but also quick feedback. :-). 

[omitted]
>    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.

Right. 

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

Actually we distinguish L3 link with L2 link. As you wrote above, when several APs 
connected to the same IP subnet, there are multiple L2 links within one L3 link.  I 
guess what you mean by 'link change' is actually 'L2 link change'. A little confusing 
terms. We contemplated a new term (e.g., IP neighborhood), but decided to keep 
using 'link' for the time being.
 
>    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.

I think that your expression is clearer. Thanks. 
 
> [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.

This is also clarifying. :-) 
 
> [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).

Thanks for useful information. 
 
> [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".

I agree that DNA schemes should inter-operate with both ND & SEND. But the 
above phase puts emphasis on security. 

Thanks for nice comments. We'll incorporate your feedback into updated version.  

Best Regards

JinHyeock