RE: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

[Samita Chakrabarti <[e-mail]>]

Hi Mikael and Mark:

Thanks for your comments and support on this draft.

The following in-line comments discusses your suggestions - the part that is covered already and the part that can be improved during the progress of the document. 



-----Original Message-----
From: Mikael Abrahamsson [mailto:[e-mail]] 
Sent: Tuesday, January 07, 2014 12:46 AM
To: Mark ZZZ Smith
Cc: Samita Chakrabarti; Ole Troan; 6man Chairs; 6man WG
Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

On Fri, 20 Dec 2013, Mark ZZZ Smith wrote:

> Perhaps it might be better to treat the link as an NBMA subnet, and 
> use
> RFC2491 "IPv6 over Non-Broadcast Multiple Access (NBMA) networks" to 
> eliminate all multicasts (including ND, MLD and application), except 
> perhaps RAs with a flag that indicate the link is operating in NBMA 
> mode (with RA timers larger than defaults - IIRC, the max router age 
> value is 90 minutes, so unsolicited RAs can be around 30 minutes apart)?

I have had similar thoughts.
[SC>] ----------------------------------------------------------

It is in fact treating somewhat similar to IPv6 over NBMA to eliminate multicast and keeping a database to register all the hosts its serving and advertising its capability of doing so in RA (E-bit).

But these networks are NOT "non-broadcast" network -- for example behavior of wireless network is shared, multi-accessed, sometimes battery powered etc.  Thus a registration is necessary to reliably handle the address resolution and duplicate address detection. Erik can provide more details on the background on the registration need by having designed both RFC4861 and the registration method mentioned in this document.

In mixed mode, the document does allow RA timers with large time-intervals. (section 12). If you prefer particular default interval [30min?], we can add a parameter in the constants section (section 20). The current text at the end of section 12 says:


"In mixed mode, the NEAR SHOULD have a configurable interval for
   periodic unsolicited router advertisements based on the media type."
[SC>] --------------------------------------------------------------------------------------------

I would like to have mode where no discovery is done at all anymore, and in order to support legacy hosts, one way of doing that would be:

Legacy hosts see RAs with M=1, and they are handed address using DHCPv6 IA_NA if they ask for it. They will not see any on-link prefix, and will send all traffic through the router. The router will install ND entry based on lifetime of the DHCPv6 IA_NA.
[SC>]----------------------------------------------------------------

The document , in mixed mode  is silent about off-link Neighbor discovery for legacy routers and enhanced mode only supports off-link ND -- thus in enhanced mode all packets are flowing through the NEAR. 
Section 12 [ mixed mode section]

"Both in mixed-mode and efficiency-aware mode, the NEAR
   sets E-bit flag in the RA and does not set 'L' on-link bit."

The document does not restrict mixed mode legacy nodes to be  off-link without understanding the full implications of the backward compatibility.

[SC>] We have a section on DHCP interaction.  Your proposal of using DHCPv6 IA_NA could apply there (section 17.3).  Let's discuss the details  off-line.

[SC>] ----------------------------------------------------
EAH will be able to do autoconfig by means of seeing an on-link /64 that is in a RA option that differs in a way that legacy hosts won't use it (preferrably also just unicasted to EAH by the router in response to RS). 
EAH use ARO to register their address just as in the draft.

If the router gets a packet to an address it doesn't have in the ND table, it just drops the packet. All traffic on the LAN is routed through the router, and optionally it can choose to send unicast redirects if it feels traffic is to hosts in the same L2 network.
[SC>] ----------------------------------------------------------------------------

Exactly. Though the document does not encourage "redirect"  messaging as it is a general support for all kinds of links from wired to lossy and non-transitive radio links, optionally one can configure to have redirect messaging if the deployment environment allows it. Here is an excerpt from the current text.

Redirect Messages:      A router SHOULD NOT send a Redirect message
                           to a host since the link has non-transitive
                           reachability.  The host behavior is same as
                           described in section 8.3 of RFC 4861[ND],
                           i,e. a host MUST NOT send or accept redirect
                           messages when in efficiency-aware mode.
                           Same as in RFC 4861[ND]


[SC>] Thanks so much.
-Samita