Subject: RE: Proposed M&O bits text for RFC2461bis

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 22 Mar 2006 00:40:32 -0500

I like Thomas's suggested changes.

Though I think that "are available" is a bit presumptuous? It may well
be that the DHCPv6 server does not exist or that there are no additional
addresses for that client. The M-bit means run stateful DHCPv6 to see
what you get, if anything.

- Bernie

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]] 
> Sent: Tuesday, March 21, 2006 8:48 PM
> To: Durand, Alain
> Cc: IPv6 Mailing List; Bob Hinden
> Subject: Re: Proposed M&O bits text for RFC2461bis 
> 
> "Durand, Alain" <[email-masked]> writes:
> 
> >  
> 
> > >     M : 1-bit "Managed address configuration" flag.  When set, it
> > >     indicates that addresses are available via Dynamic Host
> > >     Configuration Protocol [DHCPv6], including addresses that were
> > >     not configured via stateless address autoconfiguration.
> 
> 
> > I'm not sure I understand the last part of the sentence...  Does it
> > means that addresses configured via stateless address
> > autoconfiguration are -also- availabe via DHCP?
> 
> No, it means that if you don't invoke DHC to get addresses, you won't
> be getting all the addresses the network is telling you it thinks you
> need. That is, DHC is providing addresses that are (presumably) not
> available via stateless addrconf, hence you should use DHC to get
> them.
> 
> I agree the wording could be better, e.g., 
> 
>     M : 1-bit "Managed address configuration" flag.  When set, it
>         indicates that addresses are available via Dynamic Host
>         Configuration Protocol [DHCPv6], including addresses that are
>         likely not available via stateless address autoconfiguration.
> 
> 
> 
> > >          Clients SHOULD use DHC to obtain addresses
> 
> > This is the core of the suggested change going from what was the
> > equivalent of a MAY to a SHOULD... What is the rationale for that
> > change?
> 
> Per my comment above, if you don't invoke DHC, you won't get all the
> addresses the network is configured to be giving you. Hence, you
> SHOULD invoke DHC to get them.
> 
> > >         (and associated configuration information) as described in
> > [ADDRCONF].
> > >         Note that when the M bit is set, the setting of 
> the O bit is
> > >         irrelevant, since the DHC server will return "other"
> > configuration
> > >         information together with addresses.
> 
> 
> > The texts says nothing about what the client is supposed to 
> do when the
> > bit is not set.
> > (same comment with O)
> 
> Actually, the text concludes with:
> 
>        Note that if M and O are not set, clients SHOULD NOT not
>        request any information with DHC.
> 
>        
> Perhaps that should be changed to
> 
>        Note that if neither M nor O are set, clients SHOULD NOT not
>        request any information with DHC.
> 
> Thomas
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 22 Mar 2006 01:21:21 -0500

> Sent: Tuesday, March 21, 2006 7:48 PM
> To: Durand, Alain
> Cc: Bob Hinden; IPv6 Mailing List
> No, it means that if you don't invoke DHC to get addresses, 
> you won't be getting all the addresses the network is telling 
> you it thinks you need. That is, DHC is providing addresses 
> that are (presumably) not available via stateless addrconf, 
> hence you should use DHC to get them.

So, that would imply that, if you need to get more addresses,
the ones you get from stateless autoconf are not enough to operate.

In other words, addresses are not equals and some may be "better"
(for some definition of better) than the others or at least have
different
purposes...

But how does the node knows wich ones are "better", or which ones to
use?
In particular, if the node sources a datagram,
which address is it suppose to use? If we leave it to the default
address
selection rules, this ends up being defined by a longest prefix match
with
the destination, which may or may not correspond to this notion of
"better" addresses to use.

This would seem to imply that when we revisit the default address
selection
rules, we may want to add an extra rule to deal with that case.

   - Alain.

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 22 Mar 2006 01:21:21 -0500

- Alain.

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 22 Mar 2006 01:27:53 -0500

> From: Christian Huitema [mailto:[email-masked]] 
> Sent: Wednesday, March 22, 2006 12:22 AM
> To: Fred Baker; Thomas Narten
> Cc: Durand, Alain; Bob Hinden; IPv6 Mailing List
> Subject: RE: Proposed M&O bits text for RFC2461bis 
> 
>> We went through that before. The proper way for a network to 
> indicate that nodes should not use auto-conf is simply to not 
> advertise prefixes with the auto-conf bit set. If the 
> auto-conf bit is set, then hosts may obviously auto-configure 
> addresses.

The problem with the above solution is that is assume that all hosts
on the same link should be configured with the same policy,
Either all DHCP or all stateless autoconf.

If on a link I have a number of servers and a number of client PCs,
I may want to let the PC use stateless autoconf and force the servers
to use DHCP.

> 
> In fact, it would be good to be a bit more specific about the 
> expected behavior when both auto-conf and DHCP are allowed 
> (both M and A bits).
> Is the host expected to auto-allocate an address and then 
> confirm it through DHCP? Does it use the union of DHCP and 
> auto-config? What about privacy addresses?

I agree. See my previous mail.

   - Alain.

---

From: "Durand, Alain" <[email-masked]>
Date: Fri, 24 Mar 2006 10:44:09 -0500

I agree with Erik, SHOULD is premature until we clarify what the
combination of M & A means
(either with local pref, default address selection rules,...)

   - Alain.

> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Wednesday, March 22, 2006 10:19 AM
> To: Thomas Narten
> Cc: Durand, Alain; IPv6 Mailing List; Bob Hinden
> Thomas Narten wrote:
> I think making that a SHOULD is premature and too strong, 
> since we haven't explored what the desirable behaviors are 
> when both M and A bits are set.
> (When M is set and no prefix has A, then using DHCP is a no-brainer.)
> 
> I can imagine that a host wants to have the option to have 
> local policy to handle the case when both M and A bits are 
> set, but there is nothing in the "SHOULD" that allows for 
> local policy control.
> 
> If we want to work out more details in this space, I suspect 
> we need to start with understanding why some operator would 
> set both M and A bits. 
> But I think we can defer that discussion until we have more 
> deployment experience.
> 
>     Erik
> 
> 
>