RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts

I'd also suggest that members read
http://www.ietf.org/internet-drafts/draft-stenberg-pd-route-maintenance-
00.txt.

Perhaps agentopt-delegate combined with some of the concepts in this
other draft (such as Bidirectional Forwarding Detection (BFD)) can be
used to provide additional information/feedback loops to address some of
the shortcomings. In particular, if a client releases or declines a
delegated prefix or stateful address but the router fails to receive the
Reply with the updated RAAN information, the router would find out via
BFD that the client is no longer using it and could stop announcing the
route (and/or perform a leasequery to assure it has updated
information).

I too do not feel that having the DHCP server handle the route injection
is feasible; it comes with its own set of issues since the server has no
idea whether the router(s) are up, the full paths (hops) to the routers,
the metrics with which to advertise the routes, etc.

Snooping has its own set of issues and complexities. Even more so with
DHCP authentication as you probably don't want to require the relay also
have the keys. Snooping is also subject to the issues that the SRSN
option attempted to solve, so if snooping were the desired solution, we
still need the SRSN option.

- Bernie

-----Original Message-----
From: Stig Venaas [mailto:stig.venaas@uninett.no] 
Sent: Thursday, February 08, 2007 6:46 AM
To: dhcwg
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and
srsn-optiondrafts

As I wrote below, these drafts did not pass wglc. Most members of the
wg did not respond to the last call. Some of those who responded had
technical objections to agentopt-delegate.

We now need to find out what to do next. Do people believe that we
don't need this, do you believe that snooping is a fine alternative?
Or do you believe it can be done in some other way?

The main issue is how to inject the necessary routes into the routing
system. From a routing point of view it would be reasonable to have the
route announced by the router that requested and was assigned the
prefix. However this router would often be a customer router where the
ISP router would not accept such route advertisements unless it knows
they are legitimate. If the ISP router does not know what prefixes the
customer has been assigned, some form of authentication would be needed.
I don't know if that exists and it sounds complicated. agentopt-delegate
would allow the ISP router to know what prefixes to allow routes for, or
to announce routes for those itself. Another theoretical possibility 
would be for the DHCP server to somehow inject the route itself on
behalf of the customer. I believe this is generally not possible, and
does not sounds like a particularly nice solution.

In short, what I would like to ask is, what is the alternative solution,
or don't we need one? Or can the agentopt-delegate solution be improved
in some way? I would like to get some discussion on this so that we can
determine where to go next with these drafts.

Stig

Stig Venaas wrote:
> Stig Venaas wrote:
>> 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.
> 
> These drafts did not pass wg last call. It appears we need to
> further investigate whether there are better approaches, or
> maybe even whether snooping is sufficient. In particular,
> draft-stenberg-pd-route-maintenance may help us find or
> eliminate other approaches. Apart from route injection, there
> may be other reasons why the relay agent needs this information,
> e.g. access control.
> 
> Stig

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg