RE: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

[Mikael Abrahamsson <[e-mail]>]

On Wed, 21 Nov 2018, Templin (US), Fred L wrote:

> Sorry you don’t like the idea, but please don’t call it "tunneling" because
> that is not what DHCPv6ND is about. It is about a unified service that
> combines the best elements of the two services.

"RS message containing a DHCPv6 option that embeds a DHCPv6 Solicit 
message."

When I read the rest of 
https://tools.ietf.org/html/draft-templin-6man-dhcpv6-ndopt-06#section-2.2 
I read "embed" which for me is pretty much the same as "tunnel". All of 
2.2 is basically just wrapping/embedding/tunneling DHCPv6 messages in 
RS/RA messages.

Or what am I missing?

My opposition to DHCPv6 stateful here is "do we actually need everything 
that DHCPv6 does to solve our problem"? And also, do we actually want to 
do it exactly the same as DHCPv6 does it? For instance, do we want DHCPv6 
reconfigure when we instead can just send messages with 0 lifetime and 
have that mean the same thing?

>From reading your proposal, you do not say "let's just use function X, Y 
and Z of DHCPv6 and not the rest" but instead you just say "let's embed 
any DHCPv6 message and that should be supported".

There are multiple aspects of DHCPv6 that I do not like and wouldn't want 
to go into a solution you're describing. The whole relay concept in 
conjunction with PD is just not specified *at all* in any IETF document I 
know of. I've had plenty of implementation problems based on this where 
relays just did the wrong thing. I do not want to bring with us all the 
legacy that DHCPv6 has and things that are not defined.

>>> I don’t understand this either. Anything new that would be brought into
>>> IPv6ND would simply be re-creating what DHCPv6 already does.
>>
>> Yes.
>
> Good. Then we stick with DHCPv6.
>
> Thanks - Fred

Please do not put words in my mouth.

-- 
Mikael Abrahamsson    email: [e-mail]