RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-option drafts

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

Hello Jinmei,

I respect your opinion on this matter and appreciate your careful analysis,
but had a few points in follow-up regarding what you said:

  1) about multiple relay environments, 'draft-templin-autoconf-netlmm-dhcp'
    specifies a use case for RAAN/SRSN options with multiple relays.

  2) about the use of unicast, I agree that the server should not permit the
    client to use unicast when RAAN/SRSN are used.

  3) about reliability, the DHCP client is responsible for reliability. So, as
    long as there is operational assurance that all client/server messages
    will go through the relay, the relay will be updated whenever the client
    is updated.

About your recommendations:

> - relay SHOULD NOT include ORO for RAAN unless it forwards a message
>   directly to the server

This seems safe, but might not allow for multiple relays in the path. That's
OK with me, but is it OK with others?

> - server SHOULD NOT sends the Server Unicast option to the client once
>    it uses the RAAN option

Agree.

> - restrict the use of RAAN option to PD (not for address allocation)
>   at least for the  moment

I don't understand this one. Why should it be any different for address
delegation than prefix delegation? It could be, for example, that the
client requires an address to assign to an interface on a link for which
there is no prefix for stateless address autoconfiguration.

Thanks - Fred
[e-mail]
 

> -----Original Message-----
> From: JINMEI Tatuya / 神明達哉 [mailto:[e-mail]] 
> Sent: Tuesday, January 16, 2007 12:42 AM
> To: Stig Venaas
> Cc: dhcwg
> Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate 
> andsrsn-option drafts 
> 
> >>>>> 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
> 

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