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

From: Stig Venaas <[email-masked]>
Date: Thu, 08 Feb 2007 12:46:25 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Feb 2007 09:36:35 -0800

Stig,

> determine where to go next with these drafts.

As currently documented, the RAAN/SRSN options are piggybacked
on DHCP messages that pass *through* the relay on their way to
the client, and perhaps some of the concern is that the relay
might get confused because it is a middlebox and not the endpoint
responsible for reliable exchanges. So, one solution is to *make*
the relay be the endpoint responsible for reliable exchanges by
having it also configure a client function that can obtain the
RAAN/SRSN reliably through out-of-band exchanges with the server.

This would allow the same agentopt-delegate and srsn drafts to go
forward with minor modifications that talk about the out-of-band
exchanges with the relay's client. Note that this does not mean
that RAAN/SRSN options could *only* go out-of-band wrt the DHCP
exchanges btw the server and the true client; the options could
still be included in-band whenever possible and the out-of-band
mechanism used only when reliability is of concern.

Fred
[email-masked]

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 9 Feb 2007 19:28:47 -0500

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:[email-masked]] 
Sent: Thursday, February 08, 2007 6:46 AM
To: dhcwg
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and
srsn-optiondrafts

Stig

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Feb 2007 13:27:49 -0700

The way I would prefer to solve this problem is to have the DHCP  
server communicate with the routing system to inject these routes.    
And I would prefer that this *not* be part of the regular DHCP packet  
stream.

---

From: Ralph Droms <[email-masked]>
Date: Sat, 10 Feb 2007 15:33:47 -0500

How do you propose to arrange for the DHCP server to inject that routing
information, for every possible routing infrastructure deployment?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Feb 2007 13:47:05 -0700

> information, for every possible routing infrastructure deployment?

I don't know enough about routing protocols to say.   But it seems to  
be just as tractable a problem as making sure that edge routers  
inject information into the routing infrastructure, and what I like  
better about it is that it creates a situation where there is only  
one source of routing information that must be trusted, not many.    
If you have all the routers injecting routes, then you have to trust  
them all, and if you have a lot of routers, that creates a security  
and manageability problem.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 10 Feb 2007 16:23:59 -0500

Ted:

RAAN enables the ability for a trusted router to do the route injection.
For example, in the DOCSIS 3.0 environment you'd have:

HOME NETWORK <--> EROUTER <--> CABLE MODEM <--> CMTS <-+-> DHCP SERVER 
                                                       |
                                                       |
                                                       +-> Operator
Network/
                                                            Internet

The operator only trusts the CMTS (which is a relay agent) and the DHCP
Server. It can't trust any other components as those are at the
customer's premises.

So, if the EROUTER is delegated prefix, we can't trust it to inject the
routes.

But, the CMTS is trusted. And as it is a relay agent, it can:
- Snoop DHCPv6 packets to gleam the EROUTER's delegated prefix(es).
That's what is presently done for DHCPv4 (this is also done is other
deployments, such as DSL).
- Use RAAN data from the RELAY-REPLY.

The CMTS is already injecting routes into the operator's network. So,
what's wrong with having it inject the additional routes (it after all
is the target router that will deliver packets to the EROUTER).

So, what RAAN does is provide the ability for the server to communicate
to the Relay Agent (CMTS) what to inject.

With RAAN we have one known flaw -- how to handle the case when a
Release's or Decline's Reply (Relay-Reply with RAAN information) fails
to get "back" to the Relay Agent (and client). As the client may not
wait for the Reply, it and the DHCP server may think the delegated
prefix is no longer in use and the DHCP server could assign it to
another client (and perhaps on a completely different relay/router).

With Bidirectional Forwarding Detection (BFD) between the EROUTER and
CMTS, it is possible for the Relay/Router to know when the EROUTER is
down or no longer using a prefix it was delegated. Then, either the
router can stop advertising the route or perform a LeaseQuery to see if
the delegated prefix is still in use by the client.

RAAN is doing what you want -- having the DHCP server inject the routing
information -- but it is doing it through an intermediary; a relay agent
that is a router. If that router is not trusted to inject the
information, that is up to the routing system to handle.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Saturday, February 10, 2007 3:47 PM
To: Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and
srsn-optiondrafts

---

From: "Andre Kostur" <[email-masked]>
Date: Sat, 10 Feb 2007 18:27:49 -0800

Could OSPF/RIP/BGP, or some such similar routing protocol be useful for
this purpose? 

Regards,
 
Andre Kostur
Incognito Software Inc.
Senior Software Design Engineer
T: +1(604)678-2864
F: +1(604)688-4339
E: [email-masked]
 
www.incognito.com

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Saturday, February 10, 2007 12:34 PM
To: Ted Lemon; Stig Venaas
Cc: dhcwg
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and
srsn-optiondrafts

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Sun, 11 Feb 2007 06:22:13 -0500

Sure ... It *might* be useful.  But, I think we would need to show at least
an existence proof for how the DHCP server could inject routing into *any*
routing infrastructure.  We can't expect a network that has ISIS deployed to
also deploy OSPF in parallel with an ISIS-OSPF gayeway if we specify OSPF as
the way for a DHCPv6 server to inject routing information.

- Ralph

---

From: Stig Venaas <[email-masked]>
Date: Sun, 11 Feb 2007 06:11:33 +0100

> the way for a DHCPv6 server to inject routing information.

You can't generally inject a route into the routing infrastructure
specifying that the next-hop is someone else. Although I believe
OSPF supports this.

Another issue is that the DHCP server won't know whether the link to the
customer is up. If the link is down it may be best not to advertise the
route.

Stig

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 12 Feb 2007 06:57:47 -0800

> to the Relay Agent (CMTS) what to inject.

Right, and another use case is one in which the server informs
the relay about address/prefix delegations but the relay only 
keeps the knowledge to itself and does *not* inject any routes
(draft-templin-autoconf-netlmm-dhcp).

> another client (and perhaps on a completely different relay/router).

And, one solution is to have the server explicitly inform the
relay of addresses/prefixes that have been released. This works
if the relay also configures a client.

> the delegated prefix is still in use by the client.

How would this work if the EROUTER has been delegated multiple
prefixes and only releases a few of them? The EROUTER could
still appear to be up according to BFD, but defunct prefixes
might go unnoticed. 

Fred

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 12 Feb 2007 10:36:52 -0500

>if the relay also configures a client.
 
That was the point of RAAN ... But there is the issue for these
Release/Decline messages as the client may not care about the Reply and
retransmit them; hence the notification is flawed.

Perhaps we could add DHCPv6 messages between server and relay-agent that
would do this communication instead of piggybacking the RAAN data on the
Relay-Reply/Reply. The Server would send a RAAN message and retransmit
until it got a RAAN-Reply. The Relay-Forw could request the RAAN. (There
is still the case of what to do if the server's retransmissions go
unanswered, but at some point it would give up assuming the Relay was
down.)

These RAAN/RAAN-Reply messages could be relayed (to support relay
chaining in case there is another relay between the CMTS and server).
This information comes from the original relayed packet.

>still appear to be up according to BFD, but defunct prefixes

That is certainly an issue to investigate. I'm not sure how BFD or other
techniques used by routers (or proposed to be used by routers) would
handle this.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 9:58 AM
To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
andsrsn-optiondrafts

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 12 Feb 2007 08:37:33 -0800

Bernie, 

> retransmit them; hence the notification is flawed.

Yes, I think I understand the issue. What we are proposing is
that there be *two* clients - client A on the requesting router
(i.e., the "true" client) and client B on the relay agent. RAAN
options are ordinarily passed in-band on the messages from the
server to client A. But, when the server recognizes that
client A might disengate prematurely from its normal reliable
exchange (e.g., for Release and Decline) it sends its normal
replies to client A but also does an out-of-band reliable
exchange with client B so that client B is assured of getting
the RAAN options.

Note that this approach is necessary not only for clients
on requesting routers that don't complete the reliable
exchange, but also for clients that disappear from the link
unbeknownst to the relay agent (but known to the server). 
 
> Relay-Reply/Reply.

That's what we're saying.

> The Server would send a RAAN message and retransmit

What we are proposing is:

  1) Server sends Reconfigure to client B
  2) Client B sends Information-Request to server
  3) server sends Information-Reply to client B with RAAN
     options.

> This information comes from the original relayed packet.

That's fine; it would just mean that client B would have to
reside on the relay furthest from the server, i.e., the one
on the same link as client A.

> techniques used by routers (or proposed to be used by routers) would

OK. The other concern is that the BFD exchanges might not be
desireable on bandwidth-constrained links like wireless.
 
Fred

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 12 Feb 2007 11:50:24 -0500

Fred:

I think we're proposing completely different things.

If I understand your model, it is (using DOCSIS as a model) that the
relay agent (CMTS) is actually a server to the client (eRouter) and also
a client to the "real" DHCPv6 server. I am NOT propsoing that model.
While that model could be used to solve these issues, it creates a lot
of other issues (such as greater complexity in the relay as it is a
DHCPv6 server and client and Authentication is greatly complicated). I
don't like that model.

What I was suggesting is different. It is that rather than sending the
RAAN data piggybacked in the traffic going back to the client, there be
explicit (and *NEW*) messages between the server and relay to inform the
relay of the client changes. This allows for a more reliable
communication between the server and relay, especially in the case of
Release/Decline messages.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 11:38 AM
To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
andsrsn-optiondrafts

Bernie, 

 

 
Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 12 Feb 2007 09:16:53 -0800

> relay agent (CMTS) is actually a server to the client (eRouter)

No!

> and also a client to the "real" DHCPv6 server.

Yes!

> It is that rather than sending the
> relay of the client changes.

Explicit - yes; *NEW* - no. We already have
Reconfig/Info-Req/Info-Rep that the server can use to tell
a client function running on the same box as the relay agent
about the RAANs that might not otherwise get back to the
client. I have been asking for the relay agent box to also
configure a client for this purpose because it fits with the
current DHCP model in which the client function is responsible
for reliable exchanges - otherwise, I would have asked for the
DHCP model to be altered such that the server could engage in
a reliable exchange with a bare relay agent. (I could dig up
some old e-mails if necessary to show that we already explored
this angle.)

Fred

> This allows for a more reliable

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 14 Feb 2007 09:06:56 -0800

Bernie,

> unanswered, but at some point it would give up assuming the Relay was

What this implies is a bare relay agent process being able to
accept a request from a server and send a reply back. This
changes the rules of the game laid forth in RFC3315 and (had
we known that this was an option) we would have preferred an
explicit server<->relay messaging exchange over requiring the
relay agent device to also provide client process context for
reconfigure/info-req/info-reply.

As I think you know, the original proposal put forth by my
colleague several months ago was for a DHCP 'ping' message
that a server could use to test whether a relay process was
up, while at the same time conveying RAAN options to the relay.
All that is required is for the server to discover whether/not
the relay agent implements the function so that it wouldn't
try forever to reach a relay that doesn't know how to respond.

So, our preferred solition was (and still is) to specify a
mechanism whereby a DHCP server can 'ping' a DHCP relay, and
also to require that all DHCP relays that accept RAAN options
also be able to accept and respond to the ping's.

Fred

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 14 Feb 2007 12:35:40 -0500

Fred:

Can you explain the reason for the "ping"? I understand the reason for
sending RAAN information, but not what the ping is about. And is the
ping sometimes independent of RAAN delivery or always part of the RAAN
delivery?

- Bernie 

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 12:07 PM
To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
andsrsn-optiondrafts

Bernie,

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 14 Feb 2007 09:54:52 -0800

> ping sometimes independent of RAAN delivery or always part of the RAAN

There can be multiple levels of aspiration, e.g.:

 1) server pings a relay agent only for the purpose of
    reliable delivery of RAAN options
 2) server pings a relay agent for any purpose, e.g. to
    determine whether the relay is still up
 3) server pings any DHCP entity for any purpose
 4) any DHCP entity ping any DHCP entity for any purpose

We didn't get down to specific details in our discussion
several months ago, but I'm pretty sure we weren't arguing
for one approach to the exclusion of others.

Fred
[email-masked]

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 14 Feb 2007 14:03:53 -0500

Fred:

I'm trying to understand why a DHCPv6 specific message needs to be used
to do pings. Why are other techniques (such as ICMPv6 messages) not
possible to use?

And, why does the DHCPv6 server (as a DHCPv6 server) care whether a
specific relay is up or not? (Forgetting for a moment about RAAN
delivery -- ie, (2), (3) and (4) in your list below).

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 12:55 PM
To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
andsrsn-optiondrafts

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 14 Feb 2007 11:29:20 -0800

Bernie,

We were not so much seeking a specific *name* (i.e., ping)
as we were a function - in particular, "a reliable exchange
so that the server knows the stale routing state has been
purged on the path to the last-hop relay". Although we did
explore the possibility of a more general-purpose mechanism,
calling it "ping" was more for the purpose of having a
convenient way to describe it.

I don't know about practical implications for a DHCP 'ping'
that satisfies one, some or all of the levels of aspiration
I referred to. One reason to use a DHCP ping instead of an
ICMP ping would be to convey any DHCP options (RAANs and
perhaps other options) and get reachability information
in a single message exchange as opposed to multiple.

I'm having a hard time understanding this splitting of
hairs we seem to be engaged in; I think we made it
abundantly clear what we were asking for.

Fred

> From: Bernie Volz (volz) [mailto:[email-masked]] 
> Sent: Wednesday, February 14, 2007 11:04 AM
> To: Templin, Fred L; Ted Lemon; Ralph Droms (rdroms)
> Cc: dhcwg; Stig Venaas

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 14 Feb 2007 14:41:50 -0500

>abundantly clear what we were asking for. 

Sorry, but it isn't clear to me.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 2:29 PM
To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
andsrsn-optiondrafts

Bernie,

Fred