Subject: RE: [dhcwg] dhc wg last call on "DHCP Relay AgentAssignmentNotification Option"

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 10 May 2006 08:47:01 -0400

David:

If you have multiple relay agents, you'll need to solve the general
problem of how routes are advertised and removed however they "are
added" to the routing infrastructure. Snooping of packets doesn't help
(unless the relays are on the client's link and are willing to snoop all
DHCPv6 packets - including the unicast Reply's). In DHCPv6, as relay
chaining is allowed, it gets more complex if the duplicated relays
aren't on the same link as the client.

For example, if you have relay A and B on the client's link and the
Solicit/Advertise/Request/Reply goes through relay A and then at some
time later the Renew/Reply (or Release/Reply) goes through relay B,
without additional coordination between the relays, you'd end up
(assuming prefix delegation):

- For Renew/Reply, Relay B will start injecting the routes for the
delegated Prefixes. Relay A will continue to inject them until the valid
lifetime expires. Thus, for a time, both relays will advertise the
prefix; eventually only Relay B does.

- For Release/Reply, Relay B won't have a record of the delegated prefix
and may thus take no action. Relay A will continue to inject the routes
until the valid lifetime expires.

If you don't use this technique, what other means will be used to inject
these routes into the routing infrastructure? In some cases, the client
may be allowed to do it. But, in many that won't be possible as there
isn't any strong trust relationship between the client and relay.

What we're proposing isn't a perfect solution, but it is far better than
having the relays snoop the packets which is what is generally done in
v4 (though just for individual leases as there is no standardized subnet
delegation technique using DHCPv4).

If we try to solve the problem completely, we'd need to get into routing
protocols and much more. And, this isn't typical of likely 95% of the
deployments -- so why build something that is so complicated, crosses
multiple IETF WGs, has very limited scope, and takes many years to
develop. 

Let's solve the most common problem first and if there's a need, we can
look at the edge cases -- or leave that for vendors to add value.

- Bernie

> -----Original Message-----
> From: David W. Hankins [mailto:[email-masked]] 
> Sent: Tuesday, May 09, 2006 11:59 PM
> To: [email-masked]
> Subject: Re: [dhcwg] dhc wg last call on "DHCP Relay 
> AgentAssignmentNotification Option"
> 
> On Tue, May 09, 2006 at 10:09:25PM -0400, Bernie Volz (volz) wrote:
> > if the relay doesn't get the
> > message, how would the client?
> 
> Via an alternative relay agent?
> 
> -- 
> David W. Hankins		"If you don't do it right the 
> first time,
> Software Engineer			you'll just have to do 
> it again."
> Internet Systems Consortium, Inc.		-- Jack T. Hankins
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 10 May 2006 09:13:16 -0700

> prefix; eventually only Relay B does.

Sounds fine.

> until the valid lifetime expires.

Or relay B might have a record due to the first case you cited and will
withdraw its own route advertisement, but can do nothing to cause relay
A to withdraw theirs.  Which is still an identical problem.

Then, this is only a problem if the prefix is reallocated to another
client address (which may or may not be the same client) before the
lifetime expires.

So I think the question is: Does the Release only absolve the client
address binding, and not the prefix delegation binding?

Dynamic DNS, for example, is absolved on release.  So it would seem
odd for the prefix delegation to not also be absolved.

Intuitively, however, Dynamic DNS is commonly only kept, in terms of
server-kept state, on any records indicating the assignment of the
lease to the client.  Delegated prefixes, on the other hand, would
have to come out of some common pool, and when freed would have to
return there.

> isn't any strong trust relationship between the client and relay.

I'm not sure where that came from.

I'm not really following your draft very closely, I just tried to
ask a question about how the relay might get out of the loop.  I had
no idea at the time it had anything to do with route advertisements,
I was just asking if you'd considered the case of multiple relays.

At IETF 64 (I think), I thought you told me the whole question about
how routing injection/withdrawal would work would be completely out
of scope for this work.

If it's out of scope, so should this discussion be?  I admit I'm a
fairly confused about why we're even talking about this.

I thought you explicitly weren't providing any guidance for how
routing might be injected or withdrawn.

So why does it even matter if the transport is or is not reliable?

If all of this is decidedly out-of-scope, then none of it matters.

If it is in scope, then I guess we need to talk about it.

> multiple IETF WGs, has very limited scope, and takes many years to

I'm not sure what you're arguing since I haven't suggested making any
changes.

So I don't know what it is you think is 5% of deployments, has limited
scope, or takes too long to develop.

I think you're confusing my query about alternative relay agents with
a question I asked...it seems years ago now.

> look at the edge cases -

Although I admit my background is not in IPv6 broadband network
deployment, and I rather wonder who can say theirs is, my experience
in IPv4 tells me that the common problem is the one where fault
tolerant relays live.

That is, this will not fly if the architecture relies upon a single
point of failure to work.

Maybe some other operators can tell us if they prefer to use one or
two DHCPv6 relays in their broadband-access networks.

So far, all my DHCP(v4) customers (and my own preferences from
networks past) are telling me: 'two'.

So I think redundant relays has to be a given in the network
architecture this protocol would be used on.

> - or leave that for vendors to add value.

I am of the opinion that it should not take vendor value-add to make
an IETF protocol operate efficiently and normally in commonly adopted
network architecture.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg