Justify the removal of the 2hr min Valid Lifetime more thoroughly

[fgont]

FWIW, I sent a note to Suresh on the topic. Namely:

FWIW, this is the text we currently have about it: ---- cut here ----

5.3. Honor Small PIO Valid Lifetimes

The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is replaced with the following text:

  e) If the advertised prefix is equal to the prefix of an address
  configured by stateless autoconfiguration in the list, the valid
  lifetime and the preferred lifetime of the address should be
  updated by processing the Valid Lifetime and the Preferred
  Lifetime (respectively) in the received advertisement.

RATIONALE:

• This change allows hosts to react to the signal provided by a router that has positive knowledge that a prefix has become invalid.

• The behavior described in [RFC4862] had been incorporated during the revision of the original IPv6 Stateless Address Autoconfiguration specification ([RFC1971]). At the time, the IPNG working group decided to mitigate the attack vector represented by Prefix Information Options with very short lifetimes, on the premise that these packets represented a bigger risk than other ND-based attack vectors [IPNG-minutes].

   While reconsidering the trade-offs represented by such
   decision, we conclude that the drawbacks of the aforementioned
   mitigation outweigh the possible benefits.
  
   In scenarios where RA-based attacks are of concern, proper
   mitigations such as RA-Guard [RFC6105] [RFC7113] or SEND
   [RFC3971] should be implemented.

---- cut here ----

Please let us know if the above is fine. If not, how about replacing this: ---- cut here ----

While reconsidering the trade-offs represented by such decision, we conclude that the drawbacks of the aforementioned mitigation outweigh the possible benefits.

with: ---- cut here ----

     We note that Neighbor Discovery implies that Router
     Advertisement messages be trusted by SLAAC hosts [RFC3756], and
     hence an attacker has a plethora of different vectors for
     performing Denial of Service (DoS) attacks, such as forging
     RDNSS options, RIOs with more specific routes, etc.  Thus,
     while reconsidering the trade-offs represented by the current
     behavior specified in [RFC4862], we conclude that the
     drawbacks outweigh the possible benefits.

---- cut here ---- ?

Thanks!