Re: I-D Action: draft-ietf-6man-default-iids-11.txt

[Mark Smith <[e-mail]>]

Hi,

Fernando would have usually popped in by now. As he hasn't, I'll have a go.

The IIDs in this RFC are random in comparison to MAC address derived ones.
MAC address derived ones have a structure and values that can be predicted.

The IIDs are stable in comparison to RFC4942  privacy addresses, that
change every 24 hours.

These addresses aren't meant to be an alternative to privacy addresses. A
host will likely have both, with privacy addresses preferred as source
addresses for outbound connections.

For cases where privacy addresses would cause issues because they change
relatively often, these addresses would be used eg. incoming (stable)
destination addresses for servers/services that are put in DNS (eg. HTTP
server), or router interface addresses, decoupling the router interface
address from the interface/line card MAC address, so that the interface
could be swapped (meaning new MAC address) without the router's IPv6
address charging.

Regards,
Mark.

On 9 May 2016 4:35 PM, "weigengyu" <[e-mail]> wrote:
>
> Hi，
>
>
>> This document changes the default scheme for generating stable
>
>   Interface Identifiers with SLAAC to that specified in RFC7217,
>
> There is a question about RFC7217 as this draft is to promote it.
> In RFC7217,  in Page 6 and page 7,  "5.  Algorithm Specification"
> "1.  Compute a random (but stable) identifier with the expression:
>       RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)
>       Where:
>       RID:
>          Random (but stable) Identifier
>       F():
>          A pseudorandom function (PRF) that MUST NOT be computable from
>          the outside (without knowledge of the secret key).  F() MUST
>          also be difficult to reverse, such that it resists attempts to
>          obtain the secret_key, even when given samples of the output
>          of F() and knowledge or control of the other input parameters.
>          F() SHOULD produce an output of at least 64 bits.  F() could
>          be implemented as a cryptographic hash of the concatenation of
>          each of the function parameters.  SHA-1 [FIPS-SHS] and SHA-256
>          are two possible options for F().  Note: MD5 [RFC1321] is
>          considered unacceptable for F() [RFC6151]. "
>
> It seems it is a concept error for RID.
> RID is not random or random identifier according to the context above.
>
> F() is an inreverse function, not a pseudorandom function.
> Within parameters of F(Prefix, Net_Iface, Network_ID, DAD_Counter,
secret_key),
> only the secret_key is generated by a pseudorandom function.
> But the secret_key is also a constant because it keeps unchanged after
being generated.
>
> There are not random features.
>
> The question is why it is called RID, Random ID?
>
>
> Regards,
>
> Gengyu WEI
> Network Technology Center
> School of Computer
> Beijing University of Posts and Telecommunications
> -----原始邮件----- From: Alissa Cooper
> Sent: Thursday, April 28, 2016 10:41 PM
> To: IETF IPv6 Mailing List
> Subject: Re: I-D Action: draft-ietf-6man-default-iids-11.txt
>
>
> This version incorporates comments based on discussion before and during
IETF 95 (thanks to Fernando for spinning the rev). I think this version
addresses the comments received and should be ready to move forward.
>
> Alissa
>
>
>> On Apr 27, 2016, at 5:49 PM, [e-mail] wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>> This draft is a work item of the IPv6 Maintenance 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-11.txt
>> Pages           : 23
>> Date            : 2016-04-27
>>
>> Abstract:
>>   This document changes the default scheme for generating stable
>>   Interface Identifiers with 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, RFC5072, and RFC5121, by removing the text in these RFCs
>>   that required the IPv6 Interface Identifiers to be derived from the
>>   underlying link-layer address, and replacing the aforementioned text
>>   with a pointer to this document.  Additionally, this document updates
>>   RFC3315 by specifying additional requirements on the generation of
>>   Interface Identifiers used in Dynamic Host Configuration Protocol
>>   version 6 (DHCPv6).  It also provides advice to system administrators
>>   who employ manual configuration.  This document does not change any
>>   existing recommendations concerning the use of temporary addresses as
>>   specified in RFC 4941.
>>
>>
>> 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-11
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-11
>>
>>
>> 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/
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------