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

["Templin (US), Fred L" <[e-mail]>]

Hi Mikael,

> -----Original Message-----
> From: Mikael Abrahamsson [mailto:[e-mail]]
> Sent: Wednesday, November 21, 2018 8:36 AM
> To: Templin (US), Fred L <[e-mail]>
> Cc: Naveen Kottapalli <[e-mail]>; Brian E Carpenter <[e-mail]>; 6man WG <[e-mail]>;
> v6ops list <[e-mail]>
> Subject: RE: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
> 
> 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?

It is an IPv6ND option like any other - we do not call PIOs, RIOs, etc.
MTU options, etc. "tunneling".

> 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?

Do you have just one or a few use cases in mind when you say "solve our
problem"? What I am suggesting is a general purpose solution that solves
our problems, which is more or less picked up for free based on all of
the existing code.

> 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".

Why would we throw out functions that we might need in the future
if the code is already there?

> 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.

That is interesting, because DHCPv6 relay (in particular, RFC6221 Lightweight
DHCP Relay Agent) is at the heart of my implementation and works well.

>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 know what you are referring to - our relay implementation
works as it should.

Thanks - Fred

> >>> 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]