Subject: Last Call: <draft-ietf-6man-rfc4941bis-10.txt> (Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 09 Sep 2020 15:53:12 -0700

The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'Temporary Address Extensions for
Stateless Address Autoconfiguration
   in IPv6'
  <draft-ietf-6man-rfc4941bis-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-09-23. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document describes an extension that causes nodes to generate
   global scope addresses with randomized interface identifiers that
   change over time.  Changing global scope addresses over time limits
   the window of time during which eavesdroppers and other information
   collectors may trivially perform address-based network activity
   correlation when the same address is employed for multiple
   transactions by the same node.  Additionally, it reduces the window
   of exposure of a node via an address that becomes revealed as a
   result of active communication.  This document obsoletes RFC4941.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/

No IPR declarations have been submitted directly on this I-D.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 10 Sep 2020 20:26:47 +0900

Having read this document again, I have the following concerns.

1. I think it should not include section 3.3.2. The reason is that it
needlessly suggests an algorithm that is much more complex than simply
using an existing random number generator which all nodes likely already
have.
2. I think the text mentioning shorter IID lengths (3.3.1 bullet #2) is not
useful to implementers, because all it says is that it is possible to
implement a behaviour that for in all practical cases is forbidden by RFC
4291.
3. This normative text:

   1.  Process the Prefix Information Option as defined in [RFC4862],
       adjusting the lifetimes of existing temporary addresses.  If a
       received option may extend the lifetimes of temporary addresses,
       with the overall constraint that no temporary addresses should
       ever remain "valid" or "preferred" for a time longer than
       (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME -
       DESYNC_FACTOR) respectively.

does not seem to mean anything because the second sentence lacks a verb. If
a received option may extend the lifetime of temporary addressess... then
what should the implementation do? The text doesn't say.

4. This text:

   Note that, except for the
   transient period when a temporary address is being regenerated, in
   normal operation at most one temporary address per prefix should be
   in a non-deprecated state at any given time on a given interface.

seems excessive because it immediately makes all current implementations
non-compliant. It also does not seem like a good thing to limit the number
of temporary addresses in general. If an implementation wants to create
more than one for extra privacy (e.g., to use different IPv6 addresses for
different applications), it should be free to do so. This text is also not
true if a user changes TEMP_VALID_LIFETIME to a value that is not exactly
2x TEMP_PREFERRED_LIFETIME. Users are explicitly permitted to change these
values in section 3.8.

5. Should this text:

      The TEMP_PREFERRED_LIFETIME value MUST be less than the
      TEMP_VALID_LIFETIME value.

really say "less than"? Shouldn't it say "less than or equal to"?

On Thu, Sep 10, 2020 at 7:55 AM The IESG <[email-masked]> wrote:

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 10 Sep 2020 13:35:59 +0200

Le 10/09/2020 à 13:26, Lorenzo Colitti a écrit :
>  needlessly suggests an algorithm that is much more complex than
> simply using an existing random number generator which all nodes
> likely already have.

I object to that I-D paragraph at least because it says this "SHOULD
produce an output of at least 64 bits."  It should be of a more variable
length.  It is not 'at least 64bit'.

I do not oppose to the existence of that section 3.3.2.  But how would
it cope with other generated Interface Identifiers, like HIT (Host
Identity Tag) or ORCHIDs.  These are too RFCs on the Standards Track.
They too are generated by a crypto function, they too are 64bit length.
  Still they are different than this F().

As for implementation of it, think that there are already
implementations of generating Interface IDs out there, and I think none
respects what either of these documents says.

(we do have a couple of Internet Drafts under preparation, and code,
about this variable length 64bit, but for some reason it takes more
private interest and review than expected...)

Alex

> 2. I think the text mentioning shorter IID lengths (3.3.1 bullet #2)
> is not useful to implementers, because all it says is that it is
> possible to implement a behaviour that for in all practical cases is
> forbidden by RFC 4291. 3. This normative text:
> 
> received option may extend the lifetimes of temporary addresses, with
> the overall constraint that no temporary addresses should ever remain
> "valid" or "preferred" for a time longer than (TEMP_VALID_LIFETIME)
> or (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR) respectively.
> 
> does not seem to mean anything because the second sentence lacks a
> verb. If a received option may extend the lifetime of temporary
> addressess... then what should the implementation do? The text
> doesn't say.
> 
> 4. This text:
> 
> Note that, except for the transient period when a temporary address
> is being regenerated, in normal operation at most one temporary
> address per prefix should be in a non-deprecated state at any given
> time on a given interface.
> 
> seems excessive because it immediately makes all current
> implementations non-compliant. It also does not seem like a good
> thing to limit the number of temporary addresses in general. If an
> implementation wants to create more than one for extra privacy (e.g.,
> to use different IPv6 addresses for different applications), it
> should be free to do so. This text is also not true if a user changes
> TEMP_VALID_LIFETIME to a value that is not exactly 2x
> TEMP_PREFERRED_LIFETIME. Users are explicitly permitted to change
> these values in section 3.8.
> 
> 5. Should this text:
> 
> On Thu, Sep 10, 2020 at 7:55 AM The IESG <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> The IESG has received a request from the IPv6 Maintenance WG (6man)
> to consider the following document: - 'Temporary Address Extensions
> for Stateless Address Autoconfiguration in IPv6' 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to
> the [email-masked] <mailto:[email-masked]> mailing lists by 
> 2020-09-23. Exceptionally, comments may be sent to [email-masked]
> <mailto:[email-masked]> instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
> IETF IPv6 working group mailing list [email-masked]
> <mailto:[email-masked]> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 10 Sep 2020 12:58:53 +0100

> using an existing random number generator which all nodes likely already 

in theory you're probably right.  In practice, some vendors take serious 
short-cuts when it comes to prngs, particularly in the bulk-produced, 
low-cost device market. This will particularly be an issue for IoT and 
on wifi where DAD's single-shot approach is intolerant of loss.

3.3.2 only ensures that extra entropy is injected.  This probably isn't 
a bad thing.

Also the algorithm is based on rfc7217, so if there's a problem with 
this approach then that's possibly a wider discussion.

> 2. I think the text mentioning shorter IID lengths (3.3.1 bullet #2) is 
> not useful to implementers, because all it says is that it is possible 
> to implement a behaviour that for in all practical cases is forbidden by 
> RFC 4291.

It refers non-normatively to 7421, which provides a useful and nuanced 
discussion of the issue.  There doesn't seem to be any particular 
ambiguity here?

Nick

---

From: Philip Homburg <[email-masked]>
Date: Thu, 10 Sep 2020 14:41:42 +0200

>2x TEMP_PREFERRED_LIFETIME. Users are explicitly permitted to change these

Can you explain what current implementations are doing differently? As far
as I know there is usually only one temporary address that is not deprecated.

I'm not sure how it would work if you have multiple addresses that are not
deprecated. It becomes ambiguous which address will be selected by
source addresss selection.

At the same time, if an application wants to bind to a specific address then
an address only needs to valid, deprecated is fine. Even better because that
means that source address selection will not select that address (unless all
addresses are deprecated).

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Sep 2020 10:24:24 -0300

Hello, Lorenzo,

Thanks so much for your feedback! In-line....

> using an existing random number generator which all nodes likely already 

FWIW, the algorithm in Section 3.3.2 explicitly ties the MAC address to 
the resulting IID, such that a change in the MAC address (e.g. MAC 
address randomization) results in a different IID.

It's one possible algorithm, and not necessarily the recommended one.

(for instance, I did the Linux implementation of rfc4941bis, and 
employed the algorithm in Section 3.3.1, because it was simpler).

I think it can be of value, and it doesn't hurt to have it. That said, 
if there's consensus to remove it, I don't mind, either.

> to implement a behaviour that for in all practical cases is forbidden by 

Just double-checking: Are you arguing that this:

"         We note that [RFC4291] requires that the Interface IDs of all
           unicast addresses (except those that start with the binary
           value 000) be 64 bits long.  However, the method discussed in
           this document could be employed for generating Interface IDs
           of any arbitrary length, albeit at the expense of reduced
           entropy (when employing Interface IDs smaller than 64 bits)
           and increased likelihood of collision.  The privacy
           implications of the IID length are discussed in [RFC7421]."

should be removed?

> does not seem to mean anything because the second sentence lacks a verb. 
> If a received option may extend the lifetime of temporary addressess... 
> then what should the implementation do? The text doesn't say.

Good grief.

Looks like the proper fix is to s/If a received/A received/

Thoughts?

> non-compliant. It also does not seem like a good thing to limit the 
> number of temporary addresses in general.

Not sure what you mean. This text is borrowed verbatim from Section 3.4 
of RFC4941.

> If an implementation wants to 
> create more than one for extra privacy (e.g., to use different IPv6 
> addresses for different applications), it should be free to do so.

This document is an update to rfc4941, where addresses are created by 
the system, and not by an app (for instance, unfortunately I know of no 
API that allows that). i.e., it is not mean contrain apps from using 
multiple addresses.

If you had multiple preferred addresses -- as would be the case in the 
hypothetical scenario where you could create multiple temporary 
addresses -- you'd really need to explicitly bind the newly created 
address (or the API should automatically do that for you), since 
otherwise you'd not have control over which address get selected as a 
source address since you'd have multiple preferred addresses from the 
same prefixes (most likely all apps would use the same one, otherwise).
In which case, the "preferred" status would be rather irrelevant.

> This 
> text is also not true if a user changes TEMP_VALID_LIFETIME to a value 
> that is not exactly 2x TEMP_PREFERRED_LIFETIME. 

Note that the text above talks about addresses in *non-deprecated* state 
-- i.e., "preferred". if you change the TEMP_VALID_LIFETIME to something 
that's not 2x TEMP_PREFERRED_LIFETIME, you'll still have one preferred 
address (i.e., non-deprecated) and multiple in the deprecated state.

> really say "less than"? Shouldn't it say "less than or equal to"?

Tricky question :-) I guess that, strictly speaking, you could argue 
that it should be "less than or equal to". Although that would assume 
that you could be in a situation where your communications need to 
succeed and complete in a time T anywhere  T <= 1 seconds & T > 0 
seconds.  (e.g., right before the VL is decremented to 0, an app 
establishes a new connection, employing the soon-to-be-invalidated 
address).  --- this would only be a problem if DESYNC_FACTOR just 
happens to be 0, though.

Now, having looked back at this doc to answer your question, it would 
seem to me that there's a bit of ambiguity in this respect:

* Section 3,3, item 5 kind of implies that a new address is generated 
REGEN_ADVANCE seconds before the current one becomes deprecated.

* Section 3.4 says:
"  The node SHOULD start the address regeneration process
    REGEN_ADVANCE time units before a temporary address would actually be
    deprecated."

implying that this is recommended, but not really mandatory.

It would seem to me that the quoted text from Section 3.4 should be 
removed, since otherwise, as Section 3.3 item 7 require nodes to perform 
DAD, if you start to generate a temporary address once the previous one 
has been deprecated then (assuming the case where DESYNC_FACTOR = 0), 
while performing DAD for the new temporary address, the only preferred 
address for this prefix will probably be the *stable* address -- and 
clearly, if you are employing temporary addresses, you don't really want 
the stable address to be employed for outgoing communications.

Thoughts?

Also, a side comment:

REGEN_ADVANCE is specified as "5 seconds" (this comes from RFC4941). 
However, if DESYNC_FACTOR happens to be 0, and DupAddrDetectTransmits 
and RetransTimer are overriden, there could be "problematic" scenarios.

e.g. consider the case where DupAddrDetectTransmits is set to 5, and 
RetransTimer is set to 1000 ms: DAD would take 10 seconds to complete. 
So if the node starts regenerating a temporary address 5 seconds before 
the current preferred address is deprecated, then there will be a period 
of 5 seconds with no temporary addresses.

In that light, I wonder if one should specify REGEN_ADVANCE as something 
along the lines of:

REGEN_ADVANCE = 4 + (DupAddrDetectTransmits * RetransTimer / 1000)

With the default values, REGEN_ADVANCE would be "5", as in the current spec.

Or, alternatively, change the specification of DESYNC_FACTOR factor such 
that it is in the range of (DupAddrDetectTransmits * RetransTimer / 
1000) seconds and MAX_DESYNC_FACTOR.

Thoughts?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 10 Sep 2020 23:26:26 +0900

On Thu, Sep 10, 2020 at 10:27 PM Fernando Gont <[email-masked]>
wrote:

> \> 2. I think the text mentioning shorter IID lengths (3.3.1 bullet #2) is

Yes.

> Looks like the proper fix is to s/If a received/A received/

I think that might be interpreted as "A received option may extend
temporary addresses... or not, if the implementer doesn't feel like it",
which is not the intent. Maybe just "Process the Prefix Information Option
as defined in [RFC4862], adjusting the lifetimes of existing temporary
addresses, with the overall constraint that...".

> Not sure what you mean. This text is borrowed verbatim from Section 3.4

Sorry, I was misreading. Ignore this comment.

> address).  --- this would only be a problem if DESYNC_FACTOR just

Ok, so maybe clarify to say "The TEMP_PREFERRED_LIFETIME value must be less
than the TEMP_VALID_LIFETIME value to avoid disrupting existing connections
when the TEMP_PREFERRED_LIFETIME expires"?

> REGEN_ADVANCE = 4 + (DupAddrDetectTransmits * RetransTimer / 1000)

That seems better if the values are small, but if the operator does
something silly and sets DupAddrDetectTransmits to 1000 and
TEMP_PREFERRED_LIFETIME to 600 the algorithm will also not work. Maybe we
can just cap REGEN_ADVANCE to half of TEMP_PREFERRED_LIFETIME.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Sep 2020 16:21:16 -0300

On 10/9/20 11:26, Lorenzo Colitti wrote:
> On Thu, Sep 10, 2020 at 10:27 PM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

Point taken. I'll wait for others to weigh in -- me, I don't mind 
removing the text (at the end of the day, the text repeats a requirement 
from elswhere, plus notes that this mechanism can be uses for non-64 
prefixes (which should be obvious), plus notes the possible consequences 
of that, which are probably also rather obvious).

> which is not the intent. Maybe just "Process the Prefix Information 
> Option as defined in [RFC4862], adjusting the lifetimes of existing 
> temporary addresses, with the overall constraint that...".

Good. I'd just s/defined/specified/

> Ok, so maybe clarify to say "The TEMP_PREFERRED_LIFETIME value must be 
> less than the TEMP_VALID_LIFETIME value to avoid disrupting existing 
> connections when the TEMP_PREFERRED_LIFETIME expires"?

How about:
"The TEMP_PREFERRED_LIFETIME value MUST be less than the 
TEMP_VALID_LIFETIME value to avoid the pathological case where an 
address is employed for new communications, but becomes invalid in less 
than 1 second, disrupting those communications."

(i.e., disrupting long-lived existing connections that simply span past 
the lifetime of the temp address is okay and somehow expected behavior)

(After checking RFC4861, I realize that this could also happen for 
regular stable addresses, as RFC4861 allows for PL >= VL -- and in a 
way, if you do some really dumb config... well.. that's what you get). 
-- Although all rfc4941 implementations I know of perform some basic 
sanity checks on the temp_pl and temp_vl.

> TEMP_PREFERRED_LIFETIME to 600 the algorithm will also not work. Maybe 
> we can just cap REGEN_ADVANCE to half of TEMP_PREFERRED_LIFETIME.

After crafting, reviewing, and discarding :-) text a few times, it would 
seem to me that such case is somehow prevented, since the spec for 
DESYNC_FACTOR essentially says that:

DESYNC_FACTOR < TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE

since DESYNC_FACTOR is anywhere between 0 and ten minutes, we know that, 
at the very least, TEMP_PREFERRED_LIFETIME will always be larger than or 
equal to REGEN_ADVANCE. So in the "worst" case, where they are equal, as 
soon as you configure a new temporary address (i.e. it becomes 
preferred) you would start the process of creating a new one (i.e., 
producing a tentative one, and doing DAD).

That said, the text I had proposed accommodated multiple DAD 
retransmits, but failed to accommodate the possibility where DAD fails, 
and you need to retry the process.

In that case, it would seem that the best way would be to tweak the text as:

---- cut here ----
    TEMP_PREFERRED_LIFETIME -- Default value: 1 day.  Users should be
    able to override the default value.

    Note:
       The TEMP_PREFERRED_LIFETIME value MUST be less than the
       TEMP_VALID_LIFETIME value to avoid the pathological case where an
       address is employed for new communications, but becomes invalid in
       less than 1 second, disrupting those communications.

REGEN_ADVANCE -- 2 + (TEMP_IDGEN_RETRIES * DupAddrDetectTransmits * 
RetransTimer / 1000)

   Notes:
       This parameter is specified as a function of other protocol
       parameters, to account for the time possibly spent in Duplicate
       Address Detection (DAD) in the worst-case scenario of
       TEMP_IDGEN_RETRIES. This prevents the pathological case
       where the generation of a new temporary address is not started
       with enough anticipation such that a new preferred address is
       generated before the currently-preferred temporary address becomes
       deprecated.

       DupAddrDetectTransmits and RetransTimer are specified in
       [RFC4861].
---- cut here ----

Please do check if I got it right (fwiw, for the default  values, the 
above expression shields 5)

Thanks!

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Sep 2020 09:08:40 +1200

On 11-Sep-20 01:24, Fernando Gont wrote:
...
>            implications of the IID length are discussed in [RFC7421]."

It emphatically should not be removed. It's been a matter of principle
since the earliest work on IPv6 address allocation that the /64
boundary is treated like a parameter that could be changed, so
underlying code should treat it as a parameter and not as a constant.
(And RFC7421 discusses a lot more than just the privacy implications.)

So this is very important information for implementers.

   Brian

---

From: 神明達哉 <[email-masked]>
Date: Thu, 10 Sep 2020 15:33:02 -0700

At Fri, 11 Sep 2020 09:08:40 +1200,
Brian E Carpenter <[email-masked]> wrote:

> [...] It's been a matter of principle

I agree, but I think there's some subtlety here.  By referring to
RFC4291 and specifically mentioning the magic number of 64 followed by
the term "any arbitrary length", I see that the above text could read
as part of attempting to loosen or remove the magic number from the
address architecture.  Some people would think that's a good move,
while some others would consider it a very bad idea, but one clear
thing is that if we want to include this discussion in this draft it's
very unlikely to reach a consensus and the draft would hang in limbo,
if not die.

>From other responses from Fernando, I don't think that's the intent of
the authors.  In that case, if we don't want to remove the above note
because of the "lot more" in RFC7421, we might say something like
this:

   2.  The Interface Identifier is obtained by taking as many bits from
       the random number obtained in the previous step as necessary.
       See Section 2 of [RFC4862] for the necessary number of bits,
       that is, the length of the IID.  See also [RFC7421] about
       privacy implications of the IID length.  Note: there are no
       special bits in an Interface Identifier [RFC7136].
(and no "note after this)

The points of the new text are
- Use [RFC4862] about the IID length, thus making rfc4941bis agnostic
  about the "64 vs not 64" pitfall.
- Referring to RFC4862 also implicitly means the IID length is a
  parameter at least in theory, so we won't lose the "lot more" than
  privacy implications.
- On top of these, make the reference to RFC7421 focused on the
  privacy implications.

BTW, RFC4941 limits the length of IID of temporary addresses to 64
bits while noting the length is not a fixed constant:

   [...] Note that an IPv6 identifier does not
   necessarily have to be 64 bits in length, but the algorithm specified
   in this document is targeted towards 64-bit interface identifiers.
(I suspect "an IPv6 identifier" is a typo and should be "an interface
identifier")

rfc4941bis now seems to remove this limitation, albeit maybe
implicitly.  Independently from the discussion on Section 3.3.1, I
guess this change should probably be noted in Section 5 ("Significant
Changes from RFC4941").

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Sep 2020 20:18:33 -0300

Hi, Tatuya,

On 10/9/20 19:33, 神明達哉 wrote:
> address architecture. 

FWIW, at least the *intent* has been to clarified that this document is 
not tied to any specific length. In fact, I copied the relevant text 
verbatim from RFC7217.

And the text in RFC7217 was incoporated circa the same timeframe when 
people wondered where they /64 requirement came from.

[...]
> the authors.

Indeed, I had no intention whatsoever to change, loose, confuse, [or 
whaever else] the /64 requirement. -- for instance, this document 
doesn't update RFC4291, and it would seem that such an update wouldn't 
have consensus in the foreseeable future :-)

   In that case, if we don't want to remove the above note
>         special bits in an Interface Identifier [RFC7136].

If we use this text, I'd probably move the "there are nos special 
bits.." prior to the other references. But mostly just a suggestion.

> bits while noting the length is not a fixed constant:

FWIW, I think using the hard-coded "64" bits is mostly poor 
specification approach, since the IID length is described elsewhere. 
That kind of stuff should be specified in a single place, where 
appropriate, and an abstract reference should be made to that spec.

(if this was code, you'd do a #define in a single place, and just use 
that constant)

Note: I did both the Linux implementation of rfc4941bis, and a 
FreeBSD-kernel implementation (this later one not sure if it was 
committed). But of them only work with 64 bits.

So there's no "under the hoods" stuff going on...

> guess this change should probably be noted in Section 5 ("Significant

RFC4291 notes that the IID length is specified in Link-specific RFCs, 
and refrains to specify the IID in the addressing architecture. THat's 
the same we do here. And is the same we do in RFC7217.

So, if you want to implement rfc4941bis on Ethernet, you need to look at 
RFC2464, where you find that the IID is 64-bit long. This document 
(rfc4941bis) does not change or attempt to change that at all.

Thanks!

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Sep 2020 15:36:26 +1200

> (if this was code, you'd do a #define in a single place, and just use 

Technically, I think it needs to be defined separately for each interface.
So defined in the driver source code, most likely. I have no idea whether
real implementations do that.

Apart from that: I agree with Jinmei-san's approach.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Sep 2020 00:51:38 -0300

> Technically, I think it needs to be defined separately for each interface.

Yep. What I was trying to mean is that you don't plage the source code 
with a hard-coded value that is a parameter. That's bad practice.

> Apart from that: I agree with Jinmei-san's approach.

wfm, too. Lorenzo?

Thanks,

---

From: 神明達哉 <[email-masked]>
Date: Fri, 11 Sep 2020 12:17:52 -0700

At Thu, 10 Sep 2020 20:18:33 -0300,

[...]
> RFC4291 notes that the IID length is specified in Link-specific RFCs,

Do you mean RFC4862?

> (rfc4941bis) does not change or attempt to change that at all.

Right, and I have no problem with that.  But that's not my point.  I
just pointed out that RFC4941 only defined an algorithm with 64-bit
IIDs while rfc4941bis doesn't have that limitation, and that the
difference may be worth noting in the "changes from" section.  If I
were to offer some specific text, it might be something like this:

   Broadly speaking, this document introduces the following changes:
...
   o  Removes the explicit limitation of the length of interface
      identifiers: [RFC4941] is specifically targeted towards 64-bit
      interface identifiers, but this document simply refers to the
      more general specification in [RFC4862] regarding the length of
      interface identifiers.

(Here I assume rfc4941bis will adopt text like my proposal in Section
3.3.1).

That said, I wouldn't insist on having this bullet in Section 5.  If
the authors (and wg) think it's not a "significant" change, I'm okay
with not bothering to say it.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Sat, 12 Sep 2020 02:36:31 -0300

> length.  It is not 'at least 64bit'.

Huh?

SLAAC IIDs are currently required to be 64-bit long, hence the output 
should be of at least 64 bits -- if the output is 64-bits, you take all 
of them, whereas if it's more that 64-bits, you discard the exceeding bits.

>   Still they are different than this F().

This is orthogonal to this document.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 12 Sep 2020 21:49:13 +0200

> of them, whereas if it's more that 64-bits, you discard the exceeding bits.

I agree that IPv6-over-foo IIDs part of SLAAC requires that to be 64bit 
long.

And I maintain it is a wrong requirement.

The requirement should be that is a variable length.  An IID of length 
45 should work in SLAAC as much as an IID of length 72.  And 
incidentally 64, some times.

Some implementations do work the way I say it (openbsd IID length 45 or 
72 works).  Some implementation is under development in linux to make 
that work too.  They are different implementations but achieve the same 
thing.

> This is orthogonal to this document.

Hmm... orthogonal, yes, but there could be an ideal goal that RFCs at 
IETF make sense all together, I think.  If HIP protocols considers 
always that IID must be 64, but other RFCs no, then there is obviously a 
need to try to make sense all together.

True, the task might seem huge, and so we call it orthogonal: it would 
be hard to climb a vertical :-)

Alex

---

From: Fernando Gont <[email-masked]>
Date: Sun, 13 Sep 2020 01:45:16 -0300

On 12/9/20 16:49, Alexandre Petrescu wrote:
>> should be of at least 64 bits -- if the output is 64-bits, you take 
>> all of them, whereas if it's more that 64-bits, you discard the 
>> exceeding bits.
> 

While I'd probably agree, this is not the I-D where such work should be 
pursued.

> that work too.  They are different implementations but achieve the same 

To be honest, I'm curious why one would want to use *even longer* IIDs 
than /64.  (Shorter, for sure)

> need to try to make sense all together.

Doesn't HIP employ 64-bit IIDs?

> be hard to climb a vertical :-)

What I'm saying is that relaxing the requirement of 64-bits for the IID 
is out of the scope of this document.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 Sep 2020 11:28:57 +0200

Le 13/09/2020 à 06:45, Fernando Gont a écrit :
>> I agree that IPv6-over-foo IIDs part of SLAAC requires that to be 
>> 64bit long.
>>

Fair enough, the 64bit limit discussion is not the goal of this draft.

However, like all other drafts: they all claim that is not their 
problem, and they all continue with the limit.

If this draft keeps the text that is originally discussed (SHOULD 64bit) 
then this draft continues that trend.

So, if that 64bit limit were not its problem, then it would not state 
64bit.  It would be _neutral_ with respect to it.

>> Some implementations do work the way I say it (openbsd IID length 45 
>> or 72 works).  Some implementation is under development in linux to 
>> make that work too.  They are different implementations but achieve 
>> the same thing.
> 
>> always that IID must be 64, but other RFCs no, then there is obviously 
>> a need to try to make sense all together.
> 

yes it does.

> is out of the scope of this document.

I agree.  In that sense, it might be that the draft does not want to say 
64bit.

Alex