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

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 3 Jan 2007 15:46:41 -0800

Hi Stig,

Going back over the mail archives from the 05/06 timeframe,
I see now that this is the second time 'agentopt-delegate'
has been announced for wg last call - it would have been
nice to know that this is the second time around, plus a
reference to the archives from the first time.

By my reading of the archives from the previous wglc, it
seems that 'srsn-option' was created to address an issue
that was raised during the first wglc. Does that mean that
all issues raised during the first wglc are now resolved
and that this should be seen as a continuation of that
wglc? Or, is this an independent second iteration of
the wglc even though it wasn't announced as such?

In either case, IMHO readers who may not have been actively
tracking this in the 05/06 timeframe should be directed to
the archived messages.

Thanks - Fred
[email-masked]    

> -----Original Message-----
> From: Stig Venaas [mailto:[email-masked]] 
> Sent: Friday, December 29, 2006 4:45 AM
> To: dhcwg
> Subject: [dhcwg] dhc wg last call on agentopt-delegate and 
> srsn-optiondrafts 
> 
> 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.
> 
> Please respond to this WG last call.  If you support acceptance of the
> documents without change, respond with a simple 
> acknowledgment, so that
> support for the documents can be assessed.  Lack of 
> discussion does not
> represent positive support.  If there is no expression of support for
> acceptance during the WG last call, the documents will not be advanced
> to the IESG.
> 
> draft-ietf-dhc-dhcpv6-agentopt-delegate defines an option sent by a
> DHCP server to inform a DHCP relay agent of IPv6 addresses or IPv6
> prefixes that have been assigned or delegated to DHCP clients. The
> option makes use of the below srsn-option. This draft is available as
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agen
> topt-delegate-02.txt
> 
> draft-ietf-dhc-dhcpv6-srsn-option defines a Server Reply 
> Sequence Number
> option for DHCPv6. It's sent from server to relay to ensure proper
> sequencing of Relay-Reply messages. It's used by the agentopt-delegate
> option. This draft is available as
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-srsn
> -option-00.txt
> 
> Stig
> 
> _______________________________________________
> 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: Stig Venaas <[email-masked]>
Date: Thu, 04 Jan 2007 09:11:34 +0100

> reference to the archives from the first time.

Right, thanks for bringing this up. I should have mentioned
that. We did do as last call starting 8th of May 2006, and
there were some discussions on the list from 8th until the
15th. As you say srsn-option addresses one issue. It did
not pass the last call, and my idea is that this is separate.
So people that supported or were against the last draft,
should respond again (after reading through the new versions).

The idea is also that agentopt-delegate and srsn-option is
a package, so the last call is for both of these.

Stig

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Jan 2007 09:23:29 -0800

Stig, 

> 15th. As you say srsn-option addresses one issue.

OK. Then, can you (or someone who was involved in the earlier
discussions) summarize what other issues might remain?

Thanks - Fred

> It did

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 4 Jan 2007 13:25:09 -0800

> discussions) summarize what other issues might remain?

I think you mean me.

Thomas had a complaint about the use of the word 'reliable',
which I understand to have been cleared up in the edits that
brought SRSN (since that bit was edited to reference the new
draft).

I think it was only us two who said something, so that just
leaves me.

The vast exchange between Bernie and myself (throughout the
entire history of same) can be summarized I hope without
offense:

1) "Turning DHCPv6 into a kind of RIP-like thing" (my critique)
   is possibly not the most robust network design modern men can
   invent (alternatives given).
	a) But it may be the easiest to implement for CMTS people,
	   especially since CMTS already have to implement DHCPv6
	   relays.
	b) And isn't specified in this option anyway.  The entire
	   question of what you do with the contents of this option
	   are left to implementors.  It might just program an ACL
	   for a formal routing protocol (although at least this
	   purpose is one that does not strictly require the SRSN).

2) It falls down in multiple-relay (failsafe, not chained) scenarios.
	a) But there are no multiple-relay scenarios for CMTS,
	   for which this is being designed.  Such network designs
	   have 'cold spares' not 'running peers' for fault tolerance.
	b) And our volunteer is, understandably, unwilling to design
	   for multiple-relays.

So there are arguments either way.

For the record, I am abstaining from this WGLC, so nothing I just
said or am about to say should be taken in support or objection, I
just wanted to sum up for Fred.

Overall, I'm a critic of the madness rather than the method.  The
view these discussions have afforded me into this sort of madness
makes me rather glad I never worked for a Cable ISP.

I can't imagine actually craving the situation where I ask a "router"
to perform its duty without using a formal routing protocol, because
the alternative is too horrid to imagine.  In networks I have worked
at, we've always had the opposite problem: lack of adequate routing
protocol support being the horror we wished to escape [1].

But there you have it, and I accept it.  That's where these CMTS
operators are.

I cannot speak in support, for then I am helping lock the cage they
are trapped in, even if they say they like the decor.  I cannot
speak in objection, for then I am holding from them a coping
mechanism.

[1] On request, I can supply my copy of "OSPF", a song set to the
    tune of "YMCA" by _The Village People_.  It was writ, and oft
    sung over beer, by a group of people who had the misfortune of
    working with me for a company with ~300 Ascends (and we RMA'd
    30 a month).

    There is, of course, a much longer (but equally irrelevant)
    backstory behind its creation.

-- 
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

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 04 Jan 2007 16:49:46 -0500

I support the acceptance of these documents without change
and movement of them forward to the IESG.

Cheers -- Kim

At 07:45 AM 12/29/2006, Stig Venaas wrote:
>documents without change, respond with a simple acknowledgment, so that
>support for the documents can be assessed.  Lack of discussion does not
>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agentopt-delegate-02.txt
>
>draft-ietf-dhc-dhcpv6-srsn-option defines a Server Reply Sequence Number
>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-srsn-option-00.txt
>
>Stig
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Jan 2007 14:15:54 -0800

Hi David, 

> > discussions) summarize what other issues might remain?

I wasn't trying to single out anyone; I truthfully was not
aware of the 05/06 discussion thread until late yesterday
afternoon and then only had time for a quick skim.

> 	   purpose is one that does not strictly require the SRSN).

I may have a slightly different slant on this as we have
discussed before. My motivation is to reduce churn in the
backhaul network routing protocol in the presence of highly
mobile nodes (MNs).  

> 	b) And our volunteer is, understandably, unwilling to design

My scenario supports (and benefits from) multiple relays
on the link, where each relay is co-resident with a router.
MNs can use any of the available relays as a default router
but the one that actually relayed the DHCP address/prefix
delegations will be the one that receives the RAAN and SRSN
options. If the MN detects that it can no longer reach this
"primary" relay (e.g., via IPv6 NUD), it can treat this as
a link change event and issue a DHCPv6 Confirm via a new
relay. The server will reply with RAAN/SRSN options via the
new relay which will take the place of the old as the MN's
"primary" relay. 

> just wanted to sum up for Fred.

Appreciated.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Jan 2007 16:16:30 -0800

The discovery of the previous last-call discussions
and the list exchanges today haven't done anything to
change my opinion.

Yes to both (still).

Fred

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Jan 2007 15:33:16 -0700

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

I'm against advancing either of these drafts.   I think the complexity  
introduced by the SRSN option is inappropriate for DHCP, and I think  
using the DHCP protocol as a way to seed routing information is  
misguided, despite assurances that I've heard that this is no  
different than the routers option in DHCPv4.   I would prefer that if  
the DHCP server delegates a prefix, it seed the routing tables using a  
routing protocol, perhaps TBD.

I'm sorry for not having given more detailed commentary about this,  
but the fact is that my objections amount to a queasy feeling about  
the whole proposal, rather than violent, specific objection.   So I've  
been content to simply watch from the sidelines.   But I've been asked  
privately to comment, so I'm commenting.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 16 Jan 2007 17:41:52 +0900

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

> 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.
					[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Jan 2007 08:14:34 -0800

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.

> - relay SHOULD NOT include ORO for RAAN unless it forwards a message

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

Agree.

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

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

> From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]] 
> 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 
>

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 17 Jan 2007 20:23:09 +0900

>>>>> On Tue, 16 Jan 2007 08:14:34 -0800, 
>>>>> "Templin, Fred L" <[email-masked]> said:

>     will go through the relay, the relay will be updated whenever the client

That's true in most cases, but as I pointed in my previous message,
Release/Reply exchanges are an exception, that is, the server and the
client can be successfully synchronized even if some of the messages
(Reply in this case) are completely lost.  From a quick reread of
RFC3315, it also seems to apply to Decline/Reply exchanges.

> there is no prefix for stateless address autoconfiguration.

In the address allocation case, the relay (= router) should normally
know the link prefix anyway so that it can advertise the prefix in
Router Advertisements (at least with the L flag ON).  There may be
exceptional cases, of course, and if those are realistic and there's
no alternative for some reason, it may make sense to apply RAAN to
address allocation.  My point is (IMO of course) that operations
relying on RAAN (+ SRSN) are pretty dangerous with many pitfalls, and
so we should begin with very specific case(s) where we really need
RAAN without any possible alternative.

					JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 17 Jan 2007 12:06:05 -0800

> RFC3315, it also seems to apply to Decline/Reply exchanges.

In terms of Release/Reply, it sounds like you are referring here to the
case of the relay/router being left with stale state. But, if the
relay/router
also configures a client (as in
'draft-templin-autoconf-netlmm-dhcp-04.txt'),
the server can send a Reconfigure to the relay/router's client asking it
to
perform an Info-Request/Reply exchange that would convey the correct
RAAN/SRSN options. I'm sure there are other approaches too.

I don't see that Decline/Reply is quite the same, as there is no
provision
for the client to terminate the retransmission procedure early. But even
if it were the same, the same approach described above (or other
approaches) could still be used to ensure reliability.

> Router Advertisements (at least with the L flag ON).

Some links may have no prefixes, and others may have prefixes with
'A' = 'L' = 0. Clients should still be able to get an address via DHCP
w/o having to delegate an entire prefix.

> There may be
> address allocation.

OK. DHCP address delegation has the advantage that the DHCP
server ensures uniqueness. This may be necessary for links on
which RFC2462 DAD is unreliable due to message loss, on links
with asymmetric reachability, etc.

>My point is (IMO of course) that operations

As I said before, I respect your opinion. But, if there are other known
pitfalls/dangers IMO we should discuss them here and have them
out on the table. Are there others we should know about?

Thanks - Fred

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 20 Jan 2007 18:10:46 +0900

>>>>> On Wed, 17 Jan 2007 12:06:05 -0800, 

> RAAN/SRSN options. I'm sure there are other approaches too.

I'm not sure if I understand how exactly this solves the Release/Reply
case, but I won't be surprised that some additional tricks solve the
issue.  My major point here is that the current set of documents
doesn't entirely provide reliability and that achieving it (probably
by additional tricks) may not be so trivial.  This point also applies
to the Decline/Reply case.

> w/o having to delegate an entire prefix.

Then how is the RAAN option useful for the relay?  Since prefix
information is not included in address allocation via DHCPv6, I'm not
sure how the relay would act by receiving the address via RAAN.  Is
the relay intended to inject a host route to the core network 

> with asymmetric reachability, etc.

I don't understand how this is relevant to this discussion, but
allocating an address via DHCP(v6) doesn't ensure address uniqueness
anyway; the only thing the server can ensure is that no duplicate
address is allocated via DHCPv6, and there may still be other hosts
that use the allocated address.  That's why RFC2462 (and its bis)
requires DAD must be applied to any address whether it's manually
configured, configured via stateless autoconf or via DHCPv6.

> out on the table. Are there others we should know about?

I'm not sure.  I guess there are other issues, but I've not thoroughly
considered miscellaneous cases.

					JINMEI, Tatuya

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 20 Jan 2007 14:00:58 -0500

The Release/Reply and Decline/Reply issue I think basically has three cases. This assumes that the client has released or declined the address or prefix and that the server has received that and honored it, but that the Reply failed to get back to the Relay Agent and also client.

1. If the leases are not reused, there is no serious issue. The Relay Agent may continue to advertise the routes and/or allow the traffic to pass. But, as the client isn't using the prefix/address, no significant harm occurs. [This is similar to the case where the client disconnects from the network without having released the leases.]

2. If the leases are reused and delivered to the same Relay Agent (or perhaps another Relay Agent that uses some special communication mechanism with the original Relay Agent), the Relay Agent would hopefully use the client-last-transaction time to determine that the "older" information is incorrect and remove it and use the newer information. But, this is not specified in the draft.

Hum ... I thought we had added text about the client-last-transaction time option from the LeaseQuery draft to the RAAN draft, but alas I don't see it. The SRSN can't be used unless the same server sent both messages. The client-last-transaction time doesn't require synchronized clocks because it is a delta time (the only issue is any latency in packet delivery).

3. If the leases are reused and delivered to a different Relay Agent (that has no special communication with the original Relay Agent), multiple routes may be injected into the routing system and the if the old route wins, traffic may be misdirected and perhaps not delivered.

2 can be solved via the client-last-transaction time.

3 is definitely an issue as it may result in a lack of service (or intermittment service) to the client.

Without RAAN, the Relay Agents are left to snoop packets which is what we were trying to avoid. The one advantage with snooping is that the Relay can process Release/Decline messages (essentially ignoring the Reply). For other cases, it would need to process the Reply's. But I suspect this will be significantly more complex.

I guess one option we could consider is using RAAN but also requiring Relay's to snoop on Release/Decline messages as that would mean the Relay can remove the information (if found) when requested by the client. I'd prefer we not require snooping, but alas that may be needed to retain the RAAN approach.

One reason to avoid snooping is that if client uses the Auth Option, there is no way the Relay can validate this (it doesn't have the keys). With snooping for the Release/Decline, we do have a DoS attack - a rogue client can release another's addresses/prefixes.

So, looks like any way we slice this there's always going to be a loophole? 

- Bernie

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Jan 2007 08:34:02 -0800

Bernie,

> 1. If the leases are not reused, there is no serious issue. 
> The Relay Agent may continue to advertise the routes and/or 
> allow the traffic to pass. But, as the client isn't using the 
> prefix/address, no significant harm occurs. [This is similar 
> to the case where the client disconnects from the network 
> without having released the leases.]

Wouldn't it be preferable if the relay/router
could send destination unreachables back to
the source instead of just black-holing in
that case?
 
> So, looks like any way we slice this there's always going to 

There was the idea of the relay/router also
configuring a client to ensure reliability in
case the true lease-holding client has departed
or terminated the Release exchange w/o waiting
for a reply. Any problems with that?

Another idea is for the relay/router to
periodically perform NUD and then purge stale
state if the client fails to respond to its
delegations. That is what is being recommended
in NETLMM at least.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Jan 2007 08:44:38 -0800

> This point also applies to the Decline/Reply case.

Can you explain how this is so?

> the relay intended to inject a host route to the core network

To my understanding, RAAN can include IA_NA/IA_TA
as well as IA_PD. Not saying it would be desireable
in all environments but, yes, there may be cases
in which that would entail injecting host routes
and some networks may want this.

Thanks - Fred

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 22 Jan 2007 12:04:12 -0500

Hi:

See below. I was just focusing on the DHCPv6 protocol issues in my
analysis.

- Bernie 

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, January 22, 2007 11:34 AM
To: Bernie Volz (volz); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and
srsn-optiondrafts 

Bernie,

BV> Certainly the routers should do what they normally do if the
destination is unreachable and they know it isn't reachable. But in this
case it may not always know or it may take some time before this is
detected (ND timers).

BV> Yes, the router should certainly use other techniques if possible to
determine whether the destination is unreachable or not. For example,
the router can always use a routing protocol to assure that the link is
up and operational between itself and the client router.

Fred

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 23 Jan 2007 02:19:27 +0900

>>>>> On Mon, 22 Jan 2007 08:44:38 -0800, 

> Can you explain how this is so?

I don't understand why I'm being asked this (seriously), so please let
me ask you first: which part of "this point" don't you think applies
to the Decline/Reply case?  Referring to my previous message:

>> My major point here is that the current set of documents
>> by additional tricks) may not be so trivial.

are you asking about

- the current set of documents doesn't entirely provide reliability
  for the Decline/Reply case
or
- achieving it (probably by additional tricks) for the Decline/Reply
  case may not be so trivial
or both, or something else?

(For the first point, I thought it's an obvious analogy with
Release/Reply since DEC_MAX_RC is non-zero.  For the second point, I
admit "trivial" may be a subjective word, but I thought whether it's
trivial or not equally applies to Release/Reply and to Decline/Reply).

					JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Jan 2007 10:03:41 -0800

> Release/Reply since DEC_MAX_RC is non-zero.

OK, I see it now and that's all I was asking.
I made the wrong assumption that the issue
you were pointing up was due only to the fact
that the client is permitted to terminate the
Release retransmission procedure early but I
see now that both Release/Decline have a max
retry count. That's fine; both can be handled
the same way by the means I have already
explained and possibly others.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Jan 2007 10:15:40 -0800

> For example,

I don't necessarily mind your saying
"client router", but *must* the client
be a router as opposed to a simple host?

Thanks - Fred

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 22 Jan 2007 13:33:07 -0500

By definition, a host does not run routing protocols?

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, January 22, 2007 1:16 PM
To: Bernie Volz (volz); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and
srsn-optiondrafts 

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Jan 2007 12:00:40 -0800

> By definition, a host does not run routing protocols?

Sorry to confuse - as of now, we have (at least) three
solution proposals:

  1) relay/router configures client that performs reliable
     exchanges with server for Release/Decline
  2) relay/router uses NUD to detect addresses/prefixes
     that have been Released/Declined w/missing Reply
  3) relay/router and client participate in a routing
     protocol

I think cases 1) and 2) allow for the client to be a simple
host, and case 3) requires the client to be a router. Do I
have this right?

Thanks - Fred

---

From: Stig Venaas <[email-masked]>
Date: Thu, 25 Jan 2007 21:47:18 +0100

> 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