Subject: [dhcwg] draft-vijay-dhc-dhcpv6-mcast-reconf-01.txt

From: Ralph Droms <[email-masked]>
Date: Tue, 14 Dec 2004 17:42:07 -0500

At the dhc WG meeting in DC, the WG was asked to consider
draft-vijay-dhc-dhcpv6-mcast-reconf-01.txt for acceptance as a WG work item.
Here are the notes from the WG meeting:

   Park gave a summary of the draft.  Droms asked why the protocol uses
   Relay-reply message to notify router (through relay) to toggle
   'M'/'O' bits; isn't CLI sufficient?  Greg Daley suggested SNMP might
   be appropriate to cause router to toggle 'M'/'O' bits.  Some
   additional discussion about whether this mechanism is needed if
   "Information Refresh Time Option for DHCPv6" is accepted for
   standards track.  Volz pointed out that "multicast reconfig" is
   useful for unplanned renumbering.  Park was requested to provide
   more detail; further discussion will take place on the WG mailing
   list before coming to a decision about taking this draft on as a WG
   work item.

I need to be to be convinced of the need for this mechanism.  If the 
network is
being reconfigured (e.g., the link is renumbered), presumably the router must
be accessed to change its configuration.  Seems to me the router could be
caused to toggle the 'M'/'O' bits at the same time.  Why would a separate
message from the DHCP server be required?

The unsolicited Relay-reply message from the server requires changes in the
operation of the relay, so it can receive and process messages from the
server that don't have a matching Relay-forward message.

- Ralph

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 15 Dec 2004 14:55:21 +0900

>>>>> On Tue, 14 Dec 2004 17:42:07 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

> message from the DHCP server be required?

Perhaps this is not directly related to this document, but I'd like to
note that toggling the M/O flags may not help here.  In particular,
our current interpretation (as per RFC2462 and now
draft-ietf-ipv6-ra-mo-flags) is that the change from ON to OFF doesn't
have any effects on a running DHCPv6 process.  So, for example, we
cannot expect re-invocation of the process by changing the flag from
ON-to-OFF-to-ON when some network configuration changes.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Wed, 15 Dec 2004 14:41:54 +0100

> > message from the DHCP server be required?

I'm not convinced either, but I can see potential use for it.

If the router is told to announce a new prefix on the link, then I agree
that the router could be caused to toggle the bits, but at least clients
using stateless address autoconfiguration combined with stateless DHCPv6
should when seeing the new prefix hopefully make a new information-request
anyway. For clients using DHCPv6 for address configuration, the toggling
might be needed though.

There might be other cases where you want to update the client config
while the link is not renumbered. One example could be renumbering of
a link where there is a DNS server where you may need to get hosts on
other links to learn the new DNS server address. Or there may be other
changes not related to renumbering where you want clients to
reconfigure while the config on the router remains unchanged.

Even if the router config doesn't need to change, you could tell the
router via CLI/SNMP/web interface/... that it should signal hosts to
renumber. I think that might suffice.

But I can imagine cases where router and hosts are managed by
different groups of people where the people managing the hosts may not
have access to the router at all. E.g. a provider that owns the router
at the customer's site and doesn't give the customer access. In that
case I'm not sure whether the necessary trust can be established
between relay (router) and server either though.

One option might be to wait for the M/O toggling or other RA mechanism
to be deployed, and see whether there's a need for this server-relay
signalling, or if using CLI/SNMP/web interface is sufficent?

Well, it might be needed, but as I said, I'm not convinced.

> ON-to-OFF-to-ON when some network configuration changes.

I feel a bit uneasy about this toggling. I'm not sure how well it will
work in practice. Let's say you're changing a flag from ON to OFF and
back again. How long do you need it to be OFF for all clients to have
seen it? Can it be that some RAs are lost? If you need to leave it OFF
for a while, is it a problem if new clients on the link initially see
the flag being OFF? It might also be an issue with clients not
receiving RAs due to temporary link disconnection, say a wireless
client temporarily out of reach, or maybe a laptop being suspended for
a short while.

Stig

---

From: Ralph Droms <[email-masked]>
Date: Wed, 15 Dec 2004 14:02:07 -0500

Jinmei-san - seems I should get back to reading and commenting on RFC 2462
and draft-ietf-ipv6-ra-mo-flags.  Thanks...

- Ralph

At 02:55 PM 12/15/2004 +0900, JINMEI Tatuya /