Subject: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

From: [email-masked]
Date: Sun, 26 Oct 2014 11:00:03 -0700

The working group last call for this draft announced last week
continues for another week.  Please feel free to comment on it.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 26 Oct 2014 12:56:56 -0700

Hi,

Reading through this, the one thing I think that is missing, in particular as it is a problem statement, is a clear statement of what the expected behaviour actually is. I think that would certainly make it clearer why the behaviours described are then divergent.

As for the expected behaviour, I think there are actually 3 separate classes of addressing functions:

o address generation functions

The methods or algorithms used to numbers that will be used for the IPv6 address e.g., EUI-64 derived, privacy addresses, available addresses in a database etc.

o address configuration functions

The methods used to configure an address on an interface, currently SLAAC, DHCPv6, or static

o address expiry functions

The functions used to expire an address e.g., address aging/lifetimes, manual operator removal (but not SLAAC or DHCPv6)

I think it has been common for either the specifications to imply, sometimes strongly, or for people to mentally couple together two or three of them under the name of one of the address configuration functions. I think this then explains why there are the divergent behaviours described in this draft.

For example, if the implementer of DHCPv6 mentally couples together all three functions, thinking they're all part of DHCPv6, then it is logical that if DHCPv6 is switched off on a link via switching off the RA M bit, then it is logical to remove or expire the DHCPv6 learned addresses. Yet I think DHCPv6 is only an address configuration function, and if DHCPv6 is switched off, the DHCPv6 learned addresses should be left to be (normally) removed by the (DHCPv6 unrelated) address aging/lifetimes mechanism.

There are some constraints on what addressing generation functions can be used with particular address configuration functions, however, in many cases there aren't.

I don't think there is any reason why EUI-64 derived and therefore generated addresses, commonly used with SLAAC, couldn't instead by configured using static or DHCPv6 methods. RFC4941 privacy addresses, specified for use in SLAAC by RFC4941, are also supported in DHCPv6 via IA_TAs, so the method of generating privacy addresses isn't tightly bound to the address configuration method.

When thinking about/reviewing Fernando's opaque IDs a while back, which ended up being RFC7217, I realised that there was no reason why that address generation method, although specified in that RFC for SLAAC, wouldn't be just as useful when using DHCPv6 for address configuration. There is now a draft specifying how to use that address generation method with DHCPv6 (draft-ietf-dhc-stable-privacy-addresses), so it isn't tightly bound to SLAAC address configuration. If you want to implement those types of IDs before your SLAAC or DHCPv6 implementation supports them, you could generate the addresses and then apply them using the static configuration method in the interim. Fernando really just came up with an address generation method (generating Semantically Opaque Interface Identifiers) that could be used with any of the address configuration methods.

If people agree with above, then I think it would be useful to describe this break down of classes of addressing functions in this draft or perhaps another one.

Regards,
Mark.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 28 Oct 2014 01:41:41 +0000

Hi Mark,

Thanks a lot for your comments. Please see replies inline.

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Mark ZZZ Smith
> Sent: Monday, October 27, 2014 3:57 AM
> To: [email-masked]
> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
> 
> Hi,
> 
> 
> Reading through this, the one thing I think that is missing, in particular as it is
> a problem statement, is a clear statement of what the expected behaviour
> actually is. I think that would certainly make it clearer why the behaviours
> described are then divergent.
[Bing] This is indeed a good point. And I tried to discuss the expected behaviors in a dedicated draft (http://tools.ietf.org/html/draft-liu-6man-dhcpv6-slaac-implementation-guide-00).

> The methods or algorithms used to numbers that will be used for the IPv6
> address e.g., EUI-64 derived, privacy addresses, available addresses in a
> database etc.
> 
> The functions used to expire an address e.g., address aging/lifetimes,
> manual operator removal (but not SLAAC or DHCPv6)
> 
> 
> I think it has been common for either the specifications to imply, sometimes
> strongly, or for people to mentally couple together two or three of them
> under the name of one of the address configuration functions. I think this
> then explains why there are the divergent behaviours described in this draft.
[Bing] I basically share the same opinion with you. Some implementers seem to mix these separate things together. 
If you look at the above mentioned draft, the "address configuration functions" and "address expiry functions" have been covered in the document.
But I didn't think about the "address generation functions" aspect. I think it's a good concern.

> For example, if the implementer of DHCPv6 mentally couples together all
> three functions, thinking they're all part of DHCPv6, then it is logical that if
> DHCPv6 is switched off on a link via switching off the RA M bit, then it is
> logical to remove or expire the DHCPv6 learned addresses. Yet I think
> DHCPv6 is only an address configuration function, and if DHCPv6 is switched
> off, the DHCPv6 learned addresses should be left to be (normally) removed
> by the (DHCPv6 unrelated) address aging/lifetimes mechanism.
[Bing] Exactly. Fully agree.
 
> There are some constraints on what addressing generation functions can be
> used with particular address configuration functions, however, in many cases
> there aren't.
> 
> I don't think there is any reason why EUI-64 derived and therefore generated
> addresses, commonly used with SLAAC, couldn't instead by configured using
> static or DHCPv6 methods. RFC4941 privacy addresses, specified for use in
> SLAAC by RFC4941, are also supported in DHCPv6 via IA_TAs, so the method
> of generating privacy addresses isn't tightly bound to the address
> configuration method.
> 
> When thinking about/reviewing Fernando's opaque IDs a while back, which
> ended up being RFC7217, I realised that there was no reason why that
> address generation method, although specified in that RFC for SLAAC,
> wouldn't be just as useful when using DHCPv6 for address configuration.
> There is now a draft specifying how to use that address generation method
> with DHCPv6 (draft-ietf-dhc-stable-privacy-addresses), so it isn't tightly
> bound to SLAAC address configuration. If you want to implement those types
> of IDs before your SLAAC or DHCPv6 implementation supports them, you
> could generate the addresses and then apply them using the static
> configuration method in the interim. Fernando really just came up with an
> address generation method (generating Semantically Opaque Interface
> Identifiers) that could be used with any of the address configuration
> methods.
> 
> If people agree with above, then I think it would be useful to describe this
> break down of classes of addressing functions in this draft or perhaps
> another one.
[Bing] I think these are good concerns to be incorporated into the above mentioned implement-guidance draft. For the PS, currently I'm not sure whether they are out of scope, since they are for implementers not operators. I'll leave it as an open question to the WG.

Best regards,
Bing
 
> Regards,
> Mark.
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops