Subject: I-D Action: draft-ietf-6man-default-iids-03.txt

From: [email-masked]
Date: Wed, 06 May 2015 13:53:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Recommendation on Stable IPv6 Interface Identifiers
        Authors         : Fernando Gont
                          Alissa Cooper
                          Dave Thaler
                          Will Liu
	Filename        : draft-ietf-6man-default-iids-03.txt
	Pages           : 9
	Date            : 2015-05-06

Abstract:
   The IPv6 addressing architecture defines Modified EUI-64 format
   Interface Identifiers, and the existing IPv6 over various link-layers
   specify how such identifiers are derived from the underlying link-
   layer address (e.g., an IEEE LAN MAC address) when employing IPv6
   Stateless Address Autoconfiguration (SLAAC).  The security and
   privacy implications of embedding link-layer addresses in the
   Interface Identifier have been known and understood for some time
   now, and some popular IPv6 implementations have already deviated from
   such schemes to mitigate these issues.  This document changes the
   recommended default Interface Identifier generation scheme for SLAAC
   to that specified in RFC7217, and recommends against embedding link-
   layer addresses in IPv6 Interface Identifiers.  It formally updates
   RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590,
   RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC4944, RFC5072, and
   RFC5121, which require IPv6 Interface Identifiers to be derived from
   the underlying link-layer address.  Additionally, this document
   provides advice about the generation of Interface Identifiers with
   other address configuration mechanisms, such as Dynamic Host
   Configuration Protocol version 6 (DHCPv6) and manual configuration.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-6man-default-iids-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 7 May 2015 00:49:58 +0000 (UTC)

Hi,
I've one suggestion for the following text (**s)
"It is RECOMMENDED by this document that future specifications do not   specify IPv6 address generation schemes that embed the underlying   link-layer address in the IID.  Future specifications MAY use an IID   based on a node's link-layer address if design and engineering   considerations warrant. ** Note that some link-layers support locally assigned link-layer addresses [IEEE 802-2001], such as [IEEE 802.3] and [IEEE 802.11], or random addresses [Bluetooth 4.1]. Where IPv6 IIDs are to be derived from link-layer addresses, it is RECOMMENDED that the random addresses supported by the link-layer are used, or that pseudo-random locally assigned link-layer addresses are generated, assigned and used.***"
Regards,Mark.
      From: "[email-masked]" <[email-masked]>
 To: [email-masked] 
Cc: [email-masked] 
 Sent: Thursday, 7 May 2015, 6:53
 Subject: I-D Action: draft-ietf-6man-default-iids-03.txt

Abstract:

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Fri, 8 May 2015 05:58:05 +0000

Hi Mark,

Thank you for your comments. The part you added makes sense. We will update the document accordingly.

Regards,
Will (Shucheng LIU)

From: ipv6 [mailto:[email-masked]] On Behalf Of Mark ZZZ Smith
Sent: Thursday, May 07, 2015 8:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-03.txt

Hi,

"It is RECOMMENDED by this document that future specifications do not
   specify IPv6 address generation schemes that embed the underlying
   link-layer address in the IID.  Future specifications MAY use an IID
   based on a node's link-layer address if design and engineering
   considerations warrant. ** Note that some link-layers support locally assigned link-layer addresses [IEEE 802-2001], such as [IEEE 802.3] and [IEEE 802.11], or random addresses [Bluetooth 4.1]. Where IPv6 IIDs are to be derived from link-layer addresses, it is RECOMMENDED that the random addresses supported by the link-layer are used, or that pseudo-random locally assigned link-layer addresses are generated, assigned and used.***"

Regards,
Mark.

________________________________
From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Sent: Thursday, 7 May 2015, 6:53
Subject: I-D Action: draft-ietf-6man-default-iids-03.txt

Abstract:

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 9 May 2015 03:10:18 +0000 (UTC)

From: Liushucheng (Will) <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
 Sent: Friday, 8 May 2015, 15:58
 Subject: RE: I-D Action: draft-ietf-6man-default-iids-03.txt
   
#yiv1860984976 #yiv1860984976 -- _filtered #yiv1860984976 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv1860984976 {font-family:宋体;panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv1860984976 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv1860984976 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv1860984976 {panose-1:2 1 6 0 3 1 1 1 1 1;}#yiv1860984976 #yiv1860984976 p.yiv1860984976MsoNormal, #yiv1860984976 li.yiv1860984976MsoNormal, #yiv1860984976 div.yiv1860984976MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:宋体;}#yiv1860984976 a:link, #yiv1860984976 span.yiv1860984976MsoHyperlink {color:blue;text-decoration:underline;}#yiv1860984976 a:visited, #yiv1860984976 span.yiv1860984976MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv1860984976 span.yiv1860984976EmailStyle17 {color:#1F497D;}#yiv1860984976 .yiv1860984976MsoChpDefault {font-size:10.0pt;} _filtered #yiv1860984976 {margin:72.0pt 90.0pt 72.0pt 90.0pt;}#yiv1860984976 div.yiv1860984976WordSection1 {}#yiv1860984976 Hi Mark,    Thank you for your comments. The part you added makes sense. We will update the document accordingly. 
/ A further little thought, perhaps "STRONGLY RECOMMENDED" for the text I suggested, since the IPv6 IIDs are not going to be following the IID recommendations in the document?
Regards,Mark.   Regards, Will (Shucheng LIU)    

From: ipv6 [mailto:[email-masked]]On Behalf Of Mark ZZZ Smith
Sent: Thursday, May 07, 2015 8:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-03.txt    Hi,    I've one suggestion for the following text (**s)    "It is RECOMMENDED by this document that future specifications do not    specify IPv6 address generation schemes that embed the underlying    link-layer address in the IID.  Future specifications MAY use an IID    based on a node's link-layer address if design and engineering    considerations warrant. ** Note that some link-layers support locally assigned link-layer addresses [IEEE 802-2001], such as [IEEE 802.3] and [IEEE 802.11], or random addresses [Bluetooth 4.1]. Where IPv6 IIDs are to be derived from link-layer addresses, it is RECOMMENDED that the random addresses supported by the link-layer are used, or that pseudo-random locally assigned link-layer addresses are generated, assigned and used.***"    Regards, Mark.    From: "[email-masked]" <[email-masked]>
To: [email-masked] 
Cc: [email-masked] 
Sent: Thursday, 7 May 2015, 6:53
Subject: I-D Action: draft-ietf-6man-default-iids-03.txt 

Abstract:

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Mon, 18 May 2015 02:30:56 +0000

Hi Mark,

I'd keep 'RECOMMENDED' since 'STRONGLY' is not really a RFC2119 keyword, only "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL".

Regards,
Will (Shucheng LIU)

From: Mark ZZZ Smith [mailto:[email-masked]]
Sent: Saturday, May 09, 2015 11:10 AM
To: Liushucheng (Will)
Cc: [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-03.txt

________________________________
From: Liushucheng (Will) <[email-masked]<mailto:[email-masked]>>
To: Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Friday, 8 May 2015, 15:58
Subject: RE: I-D Action: draft-ietf-6man-default-iids-03.txt

Hi Mark,

Regards,
Mark.

Regards,
Will (Shucheng LIU)

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi,

Regards,
Mark.

Abstract:

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 19 May 2015 02:14:45 +0000 (UTC)

Hi Will,
In that case, sticking to RFC2119 keywords, I'd say it should be a SHOULD rather than a RECOMMENDED.
Regards,Mark.
      From: Liushucheng (Will) <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
 Sent: Monday, 18 May 2015, 12:30
 Subject: RE: I-D Action: draft-ietf-6man-default-iids-03.txt
   
#yiv0394917202 #yiv0394917202 -- _filtered #yiv0394917202 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv0394917202 {font-family:宋体;panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv0394917202 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0394917202 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv0394917202 {panose-1:2 1 6 0 3 1 1 1 1 1;}#yiv0394917202 #yiv0394917202 p.yiv0394917202MsoNormal, #yiv0394917202 li.yiv0394917202MsoNormal, #yiv0394917202 div.yiv0394917202MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:宋体;}#yiv0394917202 a:link, #yiv0394917202 span.yiv0394917202MsoHyperlink {color:blue;text-decoration:underline;}#yiv0394917202 a:visited, #yiv0394917202 span.yiv0394917202MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv0394917202 p.yiv0394917202msonormal, #yiv0394917202 li.yiv0394917202msonormal, #yiv0394917202 div.yiv0394917202msonormal {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:宋体;}#yiv0394917202 p.yiv0394917202msochpdefault, #yiv0394917202 li.yiv0394917202msochpdefault, #yiv0394917202 div.yiv0394917202msochpdefault {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:宋体;}#yiv0394917202 span.yiv0394917202msohyperlink {}#yiv0394917202 span.yiv0394917202msohyperlinkfollowed {}#yiv0394917202 span.yiv0394917202emailstyle17 {}#yiv0394917202 p.yiv0394917202msonormal1, #yiv0394917202 li.yiv0394917202msonormal1, #yiv0394917202 div.yiv0394917202msonormal1 {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:宋体;}#yiv0394917202 span.yiv0394917202msohyperlink1 {color:blue;text-decoration:underline;}#yiv0394917202 span.yiv0394917202msohyperlinkfollowed1 {color:purple;text-decoration:underline;}#yiv0394917202 span.yiv0394917202emailstyle171 {color:#1F497D;}#yiv0394917202 p.yiv0394917202msochpdefault1, #yiv0394917202 li.yiv0394917202msochpdefault1, #yiv0394917202 div.yiv0394917202msochpdefault1 {margin-right:0cm;margin-left:0cm;font-size:10.0pt;font-family:宋体;}#yiv0394917202 span.yiv0394917202EmailStyle27 {color:#1F497D;}#yiv0394917202 .yiv0394917202MsoChpDefault {font-size:10.0pt;} _filtered #yiv0394917202 {margin:72.0pt 90.0pt 72.0pt 90.0pt;}#yiv0394917202 div.yiv0394917202WordSection1 {}#yiv0394917202 Hi Mark,    I'd keep 'RECOMMENDED' since 'STRONGLY' is not really a RFC2119 keyword, only "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL".    Regards, Will (Shucheng LIU)    From: Mark ZZZ Smith [mailto:[email-masked]]
Sent: Saturday, May 09, 2015 11:10 AM
To: Liushucheng (Will)
Cc: [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-03.txt                From: Liushucheng (Will) <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Friday, 8 May 2015, 15:58
Subject: RE: I-D Action: draft-ietf-6man-default-iids-03.txt    Hi Mark,   Thank you for your comments. The part you added makes sense. We will update the document accordingly.    / A further little thought, perhaps "STRONGLY RECOMMENDED" for the text I suggested, since the IPv6 IIDs are not going to be following the IID recommendations in the document?    Regards, Mark.   Regards, Will (Shucheng LIU)      From: ipv6 [mailto:[email-masked]] On Behalf OfMark ZZZ Smith
Sent: Thursday, May 07, 2015 8:50 AM
To: [email-masked];[email-masked]
Cc: [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-03.txt   Hi,   I've one suggestion for the following text (**s)   "It is RECOMMENDED by this document that future specifications do not    specify IPv6 address generation schemes that embed the underlying    link-layer address in the IID.  Future specifications MAY use an IID    based on a node's link-layer address if design and engineering    considerations warrant. ** Note that some link-layers support locally assigned link-layer addresses [IEEE 802-2001], such as [IEEE 802.3] and [IEEE 802.11], or random addresses [Bluetooth 4.1]. Where IPv6 IIDs are to be derived from link-layer addresses, it is RECOMMENDED that the random addresses supported by the link-layer are used, or that pseudo-random locally assigned link-layer addresses are generated, assigned and used.***"   Regards, Mark.   

Abstract:

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Tue, 19 May 2015 11:05:48 +0000

Hi Mark,

I didn’t get your point. RECOMMENDED is in RFC2119 keyword list.

Regards,
Will (Shucheng LIU)

From: Mark ZZZ Smith [mailto:[email-masked]]
Sent: Tuesday, May 19, 2015 10:15 AM
To: Liushucheng (Will)
Cc: [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-03.txt

Hi Will,

Regards,
Mark.

Hi Mark,

Regards,
Will (Shucheng LIU)

From: Mark ZZZ Smith [mailto:[email-masked]]
Sent: Saturday, May 09, 2015 11:10 AM
To: Liushucheng (Will)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: I-D Action: draft-ietf-6man-default-iids-03.txt

Hi Mark,

Regards,
Mark.

Regards,
Will (Shucheng LIU)

Hi,

Regards,
Mark.

Abstract:

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 19 May 2015 22:56:27 +0000 (UTC)

Hi Will,
I think the RFC 2119 equivalent of "strongly RECOMMENDED" is "SHOULD", so I think "SHOULD" should be used.
I don't think RECOMMENDED is strong enough - recommendation advice is close to "if you feel like it". If the IIDs are going to be derived from link-layer addresses, and those link-layer addresses can be made random, so that the randomness property carries over to the derived IIDs, then I think a statement that this SHOULD be done is consistent with the theme of the draft.
Regards,Mark.

 Sent: Tuesday, 19 May 2015, 21:05
   
#yiv1750598414 #yiv1750598414 -- _filtered #yiv1750598414 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv1750598414 {font-family:宋体;panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered #yiv1750598414 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv1750598414 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv1750598414 {panose-1:2 1 6 0 3 1 1 1 1 1;}#yiv1750598414 #yiv1750598414 p.yiv1750598414MsoNormal, #yiv1750598414 li.yiv1750598414MsoNormal, #yiv1750598414 div.yiv1750598414MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:宋体;}#yiv1750598414 a:link, #yiv1750598414 span.yiv1750598414MsoHyperlink {color:blue;text-decoration:underline;}#yiv1750598414 a:visited, #yiv1750598414 span.yiv1750598414MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv1750598414 p.yiv1750598414msonormal, #yiv1750598414 li.yiv1750598414msonormal, #yiv1750598414 div.yiv1750598414msonormal {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:宋体;}#yiv1750598414 p.yiv1750598414msochpdefault, #yiv1750598414 li.yiv1750598414msochpdefault, #yiv1750598414 div.yiv1750598414msochpdefault {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:宋体;}#yiv1750598414 p.yiv1750598414msonormal1, #yiv1750598414 li.yiv1750598414msonormal1, #yiv1750598414 div.yiv1750598414msonormal1 {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:宋体;}#yiv1750598414 p.yiv1750598414msochpdefault1, #yiv1750598414 li.yiv1750598414msochpdefault1, #yiv1750598414 div.yiv1750598414msochpdefault1 {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:宋体;}#yiv1750598414 span.yiv1750598414msohyperlink {}#yiv1750598414 span.yiv1750598414msohyperlinkfollowed {}#yiv1750598414 span.yiv1750598414msohyperlink1 {}#yiv1750598414 span.yiv1750598414msohyperlinkfollowed1 {}#yiv1750598414 span.yiv1750598414emailstyle171 {}#yiv1750598414 span.yiv1750598414emailstyle27 {}#yiv1750598414 p.yiv1750598414msonormal2, #yiv1750598414 li.yiv1750598414msonormal2, #yiv1750598414 div.yiv1750598414msonormal2 {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:宋体;}#yiv1750598414 span.yiv1750598414msohyperlink2 {color:blue;text-decoration:underline;}#yiv1750598414 span.yiv1750598414msohyperlinkfollowed2 {color:purple;text-decoration:underline;}#yiv1750598414 p.yiv1750598414msonormal3, #yiv1750598414 li.yiv1750598414msonormal3, #yiv1750598414 div.yiv1750598414msonormal3 {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:宋体;}#yiv1750598414 p.yiv1750598414msochpdefault2, #yiv1750598414 li.yiv1750598414msochpdefault2, #yiv1750598414 div.yiv1750598414msochpdefault2 {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:宋体;}#yiv1750598414 p.yiv1750598414msonormal11, #yiv1750598414 li.yiv1750598414msonormal11, #yiv1750598414 div.yiv1750598414msonormal11 {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:宋体;}#yiv1750598414 span.yiv1750598414msohyperlink11 {color:blue;text-decoration:underline;}#yiv1750598414 span.yiv1750598414msohyperlinkfollowed11 {color:purple;text-decoration:underline;}#yiv1750598414 span.yiv1750598414emailstyle1711 {color:#1F497D;}#yiv1750598414 p.yiv1750598414msochpdefault11, #yiv1750598414 li.yiv1750598414msochpdefault11, #yiv1750598414 div.yiv1750598414msochpdefault11 {margin-right:0cm;margin-left:0cm;font-size:10.0pt;font-family:宋体;}#yiv1750598414 span.yiv1750598414emailstyle271 {color:#1F497D;}#yiv1750598414 span.yiv1750598414EmailStyle38 {color:#1F497D;}#yiv1750598414 .yiv1750598414MsoChpDefault {font-size:10.0pt;} _filtered #yiv1750598414 {margin:72.0pt 90.0pt 72.0pt 90.0pt;}#yiv1750598414 div.yiv1750598414WordSection1 {}#yiv1750598414 Hi Mark,    I didn’t get your point. RECOMMENDED is in RFC2119 keyword list.    Regards, Will (Shucheng LIU)    

Subject: Re: I-D Action: draft-ietf-6man-default-iids-03.txt    Hi Will,    In that case, sticking to RFC2119 keywords, I'd say it should be a SHOULD rather than a RECOMMENDED.    Regards, Mark.    From: Liushucheng (Will) <[email-masked]>
Subject: RE: I-D Action: draft-ietf-6man-default-iids-03.txt    Hi Mark,   I'd keep 'RECOMMENDED' since 'STRONGLY' is not really a RFC2119 keyword, only "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL".   Regards, Will (Shucheng LIU)   From: Mark ZZZ Smith [mailto:[email-masked]]
Subject: RE: I-D Action: draft-ietf-6man-default-iids-03.txt   Hi Mark,   Thank you for your comments. The part you added makes sense. We will update the document accordingly.   / A further little thought, perhaps "STRONGLY RECOMMENDED" for the text I suggested, since the IPv6 IIDs are not going to be following the IID recommendations in the document?   Regards, Mark.   Regards, Will (Shucheng LIU)     From: ipv6 [mailto:[email-masked]]On Behalf Of Mark ZZZ Smith

Abstract:

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 May 2015 11:29:25 +1200

> I think the RFC 2119 equivalent of "strongly RECOMMENDED" is "SHOULD", so I think "SHOULD" should be used.

SHOULD and RECOMMENDED are defined as identical by RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Humans might interpret the words differently, but formally they
are the same. Good practice is to list an exclusive set of
reasons to ignore the recommendation.

The only stronger wording that I know of is MUST...unless...
(or REQUIRED...unless... if you want an adjective), or some
equivalent. In RFC 7045 we did it this way:

   A forwarding node
   MUST either leave a non-zero flow label value unchanged or change it
   only for compelling operational security reasons as described in
   Section 6.1.

     Brian