Re: <draft-ietf-6man-default-iids> update to rfc2464bis

[Fernando Gont <[e-mail]>]

On 01/12/2017 05:24 AM, Lorenzo Colitti wrote:
> On Thu, Jan 12, 2017 at 4:20 PM, Fernando Gont <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     > We do
>     > recommended that nodes use RFC7217 addresses by default, but only if the
>     > node wishes to create stable addresses, and there is no requirement that
>     > a node do so.
> 
>     So far, the current specs essentially require that. RFC4941 (the only
>     spec we have for non-temporary addresses) require that the be generated
>     along with the traditional (stable) addresses.
> 
> 
> I don't see what RFC 4941 has to do with this discussion. RFC4941 is a
> method of generating temporary addresses. It is not required to be used,
> and it is not the only way of forming IP addresses that can change over
> time.

If you use temp-only, that means the inability to have e.g. long-lived
SSH sessions. I don't think that's the current operating "model", even
less for IPv6.



>     FWIW, I do think there are scenarios in which you might want to do
>     temporary-only, but we certainly need an update to the current specs in
>     that regard (and guidance regarding where to use each).
> 
> 
> There are lots of ways of forming interface identifiers. We should
> absolutely not rule out the ability to form IIDs from non-stable MAC
> addresses (IIRC the text in default-iids was carefully modified to
> ensure that that would still be possible, based on substantial
> discussions in the WG), and we should *absolutely* not say that the only
> possible form of interface identifiers on an Ethernet interface are
> RFC7217 and RFC4941.

Clearly, default-iids talks about stable-iids, and the default algorithm
for such iids. And nobody said otherwise.

So far, the only two standardized algorithms for generating IIDs with
SLAAC are RFC7217, RFC4941, and traditional slaac (modified eui-64).
Clearly, you can hack your code and commit it. Being that this is
standardization body, I would expect that we're agree on standardizing
reasonable approaches, and calling bad approaches as such.

Better to have us discuss approaches and std'ize them, that have each
vendor come up with their own (possibly flawed) approach.

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