Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-option drafts

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

>>>>> On Fri, 29 Dec 2006 13:45:15 +0100, 
>>>>> Stig Venaas <[e-mail]> said:

> This message announces a wg last call on two drafts. They are
> DHCPv6 Relay Agent Assignment Notification (RAAN) Option
> <draft-ietf-dhc-dhcpv6-agentopt-delegate-02.txt>

> and

> DHCPv6 Server Reply Sequence Number Option
> <draft-ietf-dhc-dhcpv6-srsn-option-00.txt>.

> The last call will conclude at 1700EST on Mon, 2007-01-15.

Sorry for the delayed response, but in case it's not too late I'd like
to express my agreement with David and Ted, that is, I cannot support
this set of drafts.

I share the same concerns with them; in general, it seems dangerous to
define such general options even though there will be many scenarios
where they don't work:

- as others pointed out, this approach won't work (or at least will
  cause troubles/confusion such as creation of an unreachable route or
  a routing loop) in a multiple-relay environment

- this approach will won't work either if the client and server uses
  unicast communication for Request/Reply and subsequent exchanges.

- even with the introduction of the SRSN option, the mechanism is
  still not really reliable.  For example, consider the case where a
  requesting router of PD was allocated an IPv6 prefix and then has
  released it, but all Reply messages are somehow lost between the
  server and the relay (not the requesting router).  Then the
  requesting and delegating routers can successfully remove the
  binding despite the lost messages, but a stale state about the
  prefix will still remain in the relay.

Also, while the specification is generic (despite many non-workable
cases) so that it can be applied to address allocation, I doubt the
usefulness of this usage because in that case the relay (=router)
should normally know the link prefix anyway and doesn't need the
information contained in the RAAN in practice.

I'd rather employ an "eviler" approach such as snooping DHCPv6
messages at the relay (just like in an IGMP/MLD snooping swith) for
the particular issue that this set of proposal seems to try to
address.  It won't be fully reliable either, but since the proposed
method is also not really reliable as pointed out above, I'd prefer
not creating a risky general extension to the standard protocol.
Alternatively, the relay and the server may directly communicate using
some different protocol than DHCP over a reliable channel about the
resources the server has allocated via the relay (of course, this
approach would also have a limitation in a multi-relay environment).

Having said that, I'd also hesitate to oppose to advancing these
document since I understand these drafts are proposed to address a
real world issue in an actual deployment scenario of IPv6/PD and I
don't want to prevent the deployment by objecting to a key feature to
make it happen, especially when there's no possibility for
alternatives to be adopted (and that's my understanding).

So...like David, the only position I can take seems to be abstention.
But if there is a room to add something, I'd like to clarify the
intended usage of these options, discouraging or even disallowing
other use cases.  For example,

- relay SHOULD NOT include ORO for RAAN unless it forwards a message
  directly to the server
- server SHOULD NOT sends the Server Unicast option to the client once
  it uses the RAAN option
- restrict the use of RAAN option to PD (not for address allocation)
  at least for the moment

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

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