Re: [RTG-DIR] RtgDir review:draft-ietf-6man-resilient-rs-04

[James Woodyatt <[e-mail]>]

The inference that a link is not IPv4-only after receiving an ICMPv6 Route
Advertisement message with zero lifetime is interesting.

Here's why an interesting thing to me: on my home network, the Nest Protect
and Nest Learning Thermostats periodically send RA messages with zero
lifetime, so they can inform hosts of the ULA prefix assigned for what we
call their "fabric" (an application protocol concept).  Therefore, under
the requirement language in this draft, hosts that implement Resilient
Router Solicitation on links where Nest devices are present, which are
otherwise functionally IPv4-only, will never stop sending their RS
messages. So, the objective here— allowing hosts to turn off soliciting on
IPv4-only links— seems like it might be difficult to achieve on networks
where RA messages are only ever used for local prefix distribution and no
IPv6 default router is actually deployed.

I actually think the more problematic sentence is the first one Mr.
Ginsberg quoted, not the second one.  I don't think hosts can easily infer
that a link is IPv4-only, and the sentence that says hosts may stop sending
RS messages when "it is willing to accept that no [IPv6 default] router
exists [or will exist in the foreseeable future]" is the one that's loaded
with too much ambiguity [see my bracketed assumptions, which may be wrong].

I'm not sure what to say about this except that maybe allowing hosts to
stop sending RS messages because they have inferred that the network is
IPv4-only is an unnecessary concession to legacy deployments. Perhaps it
would be better to define a new DHCPv4 option that dual-stack hosts may use
as an explicit signal that IPv6 Resilient Router Solicitation is unwelcome
on the link.

On Tue, Feb 17, 2015 at 8:39 PM, Suresh Krishnan <
[e-mail]> wrote:

> Hi Les,
>   Thanks a lot for your review. Please find my responses inline.
>
> On 02/16/2015 05:09 AM, Les Ginsberg (ginsberg) wrote:
>
>> Hello,
>>
>> I have been selected as the Routing Directorate reviewer for this draft.
>> The Routing Directorate seeks to review all routing or routing-related
>> drafts as they pass through IETF last call and IESG review, and
>> sometimes on special request. The purpose of the review is to provide
>> assistance to the Routing ADs. For more information about the Routing
>> Directorate, please see http://trac.tools.ietf.org/
>> area/rtg/trac/wiki/RtgDir
>>
>> Although these comments are primarily for the use of the Routing ADs, it
>> would be helpful if you could consider them along with any other IETF
>> Last Call comments that you receive, and strive to resolve them throug
>> discussion or by updating the draft.
>>
>> Document: draft-ietf-6man-resilient-rs-04
>> <https://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs/>
>>
>>
>> Reviewer: Les Ginsberg
>>
>> Review Date: February 16, 2015
>>
>> IETF LC End Date: February 16, 2015
>>
>> Intended Status: Standard
>>
>> Summary:  This document is basically ready for publication, but has one
>> substantive issue that would require some text changes prior to
>> publication.
>>
>> Major Issues: None
>>
>> Minor Issues: I admit to not having followed the progress of this
>> document prior to my review - but I have read the email archives and do
>> understand that the scope of this document has been deliberately limited
>> and there has been significant "wordsmithing" of the document to reflect
>> the limited scope. I am therefore a bit reluctant to suggest further
>> changes - but I thought this might be worth discussing.
>>
>> The mechanism defined in this document allows a host to send RSs beyond
>> what is defined in RFC 4861. Use of this mechanism is optional. The only
>> MUST which this document imposes is that if a host chooses to use the
>> mechanism defined it MUST use the backoff algorithm defined in Section 2
>> of this document. However, Section 2 explicitly states that a host is
>> free to cease sending RSs whenever
>>
>> "it is willing to accept that no router exists"
>>
>> I therefore find the following sentence in Section 2.1 inappropriate:
>>
>> "If an RA is recieved from a router and it does not result in a default
>> route (i.e. Router Lifetime is zero) the host MUST continue
>> retransmitting the RSs."
>>
>> I think this sentence should be removed. I believe the intent of the
>> sentence is to indicate that the reception of an RA provides positive
>> indication that IPv6 is enabled on the interface and therefore it is
>> useful to continue to utilize the mechanism - but the introduction of a
>> MUST here is in contradiction to the earlier quote from Section 2 (see
>> above). It also raises the unanswered question as to how long a host
>> MUST continue to send RSs once it has received an RA.
>>
>
> The exception text was added to allow such hosts to turn off soliciting on
> IPv4-only links. Once an RA is received from a router (even when the router
> is not willing to the default router), it signals to the host that the link
> is not an IPv4-only link. Hence the MUST for the host to continue sending
> the RSes. Does that make sense?
>
>
>> Nits:
>>
>> Should you decide to keep the above sentence in Section 2.1 note that
>> "recieved" is misspelled. :-)
>>
>
> Will fix. Thanks.
>
> Regards
> Suresh
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
james woodyatt <[e-mail]>
Nest Labs, Communications Engineering