Subject: [dhcwg] dhc WG meeting summay

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Nov 2006 08:41:42 -0500

Included below is a summary of the WG meeting and document actions taken
during the meeting.  Please review and reply with comments by Fri, Nov 17.
If there are no comments, we will begin confirming the document actions on
the WG mailing list next week.

- Ralph

                           dhc WG meeting summary
                                 Nov 8, 2006

Draft last call and adoption announcements

WG last call:
draft-ietf-dhc-dhcpv6-agentopt-delegate-01
draft-volz-dhc-dhcpv6-srsn-option-00

  These two drafts will be submitted as a package to IESG.
  draft-volz-dhc-dhcpv6-srsn-option-00 was accepted as a WG work item
  on Oct 27.
  Consensus in the room to go to WG last call; to be confirmed on WG
  mailing list after draft-volz-dhc-dhcpv6-srsn-option-00 is
  republished as dhc WG work item draft-ietf-dhc-dhcpv6-srsn-option-00

draft-ietf-dhc-dhcpv6-reconfigure-rebind-00
  Clarifies text in 3315 about where client sends response to
  Reconfigure, and that Reconfigure message can cause client to send
  Rebind as well as Renew.  To be written as new RFC updating RFC 3315
  rather than as an errata.
  Consensus in the room to go to WG last call; to be confirmed on WG
  mailing list

draft-ietf-dhc-subnet-alloc-04
  Consensus in the room to go to WG last call; to be confirmed on WG
  mailing list; concerns about IPR statement to be addressed during WG
  last call

draft-ietf-dhc-dhcpv6-ero-00
  Consensus in the room to go to WG last call; to be confirmed on WG
  mailing list

draft-ietf-dhc-failover-12.txt
  After a long period of inactivity, interest in moving I-D forward
  expressed from 3 sources independently.  Interested parties to meet
  after WG meeting to form ad hoc design team to develop an action
  plan.

WG rechartering
  WG chairs have updated charter.  No objections to charter during
  brief review in WG meeting.  WG to discuss revised charter on WG
  mailing list.

draft-daniel-dhc-mihis-opt-02
  Need to confirm with IEEE 802.21 about need for this option and
  about design in IEEE 802.21 WG.

draft-ietf-dhc-dhcvp6-leasequery-00
  Consensus in the room to go to WG last call; to be confirmed on WG
  mailing list.

draft-stenberg-pd-route-maintenance-00
  Further discussion needed

draft-volz-dhc-dhcpv6-srsn-option-00
  Consensus in the room to go to WG last call; to be confirmed on WG
  mailing list.
 
draft-templin-autoconf-netlmm-dhcp-04
  No WG action; WG members encouraged to attend netlmm WG meeting

draft-ietf-dhc-pxelinux-00
  Consensus in the room to go to WG last call for Informational RFC;
  to be confirmed on WG mailing list.

draft-dhankins-atomic-dhcp-00
  Consensus in the room to take on this draft as a WG work item
  (Informational RFC); to be confirmed on WG mailing list.

draft-joshi-dhcp-lease-query-ext-02
draft-decnodder-dhc-rai-unicast-01
  No consensus to take on these drafts as WG work item at this time.

draft-sarikaya-dhc-proxyagent-00
  No consensus to take on this draft as WG work item at this time.

draft-fujisaki-dhc-addr-select-opt-02
  Need to wait for work in v6ops before taking on design of this
  option in dhc WG

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Nov 2006 10:30:27 -0800

There was a proposal at the meeting to rename the
Relay Agent Assignment Notification (RAAN) option
as the Classless Static Route (CSR) option for
DHCPv6 (i.e., the DHCPv6-equivalnet of RFC3442),
and it was suggested to take the discussion to
the list. Reasons to rename the option include:

  1) symmetry with DHCPv4
  2) promote existing DHCPv4 option to DHCPv6 
  3) simplify documentation ("CSR" used for
     both DHCPv6; DHCPv4)

As an example of a document that is simplified by
using the same term (CSR) to identify both the
DHCPv4 and DHCPv6 options, see:

http://www.ietf.org/internet-drafts/draft-templin-autoconf-netlmm-dhcp-0
4.txt

Comments?

Fred
[email-masked] 

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Monday, November 13, 2006 5:42 AM
To: dhcwg
Cc: Stig Venaas
Subject: [dhcwg] dhc WG meeting summay

Included below is a summary of the WG meeting and document actions taken
during the meeting.  Please review and reply with comments by Fri, Nov
17.
If there are no comments, we will begin confirming the document actions
on
the WG mailing list next week.

- Ralph

                           dhc WG meeting summary
                                 Nov 8, 2006

WG last call:

WG rechartering

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 13 Nov 2006 14:03:27 -0800

> http://www.ietf.org/internet-drafts/draft-templin-autoconf-netlmm-dhcp-0

Unless I am completely mistaken, this documents Mobile Nodes
(MN) as DHCPv4 and DHCPv6 "Clients".  Access Routers (AR)
as DHCPv4 and DHCPv6 "Relays".

It is the AR's which wish to consume the "CSR" as defined in
your draft?

It's a bit strange already that you're suggesting a DHCPv4 relay
would 'snoop' packet contents intended by the server for the
client.

> Comments?

Well, go ahead, give me an excuse why don't you?

RAAN was really intended for relay agents, and the document
does detail that this option is to be included at the 'relay
reply' level only...it goes into some detail...including
requiring the DHCP server to submit the option to the relay
in its reply to a release message (again at the relay-reply
level), with zeroed lifetimes.  Effectively instructing the
relay to remove the route.  This is, in my opinion, *not*
elevating DHCPv4 CSR to DHCPv6.

It is more similar to elevating IPv4 RIP to DHCPv6, but still
different enough not to make that comparison entirely fair.

The CSR routes used for clients in DHCPv4 were substantially
more 'informative'.  The RAAN is much more 'programmatic'.
The implementation requirements are substantially different.

It certainly isn't expected for DHCPv4 clients to populate an
ACL or to propogate the routes received, and I would be
concerned if there were any suggestion a client should do so,
or that a relay should propogate routes 'advertised' in a
packet it witnessess to be bound for a client.

I don't think we're looking at exhausting the 16-bit option
space anytime soon.  So I would suggest making these two use
cases two different options.

The intent being to make the implementation details on those
clients that consume "CSR" information far more lenient and
optional than is required for the relay's use case in RAAN,
not the least of which I would hope is to remove all mention
of propogating routes.

In summary, you're looking for a DHCPv4 RAAN, if I understad
your document correctly, not a DHCPv6 CSR.

I'm also equally skeptical about that as I have been about
RAAN.  These are routing problems being solved with a
configuration protocol.

It would be nice if an actual routing protocol could be used,
possibly /configured/ into operation via DHCPvX.

-- 
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: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Nov 2006 16:03:49 -0800

Hi David, 

Cutting down a bit:

> as DHCPv4 and DHCPv6 "Relays".

Right, but the ARs also configure DHCP clients that speak
to the server on behalf of MNs that have recently departed
and/or MNs that do not use DHCP themselves.

> It is the AR's which wish to consume the "CSR" as defined in

Yes.

> would 'snoop' packet contents intended by the server for the

The way the draft is currently specified, it is true that
the DHCPv4 relay is expected to 'snoop' packet contents
for the case of adding routes. But, if we wanted a totally
unmodified relay the MAP could do a FORCERENEW/INFORM/REPLY
exchange with the AR's client function with CSRs containing
routes to be added, i.e., we could make it symmetric with
the route deletion case.

> elevating DHCPv4 CSR to DHCPv6.

Well, DHCPv4 CSRs carry (address/prefixlen, nexthop)-tuples
and DHCPv6 RAANs carry addresses and/or prefixes with with
associated lifetimes so there are differences. But, both are
used for the purpose of configuring routing information in
the network equipment associated with the entity that processes
the options. It seems safe to call them "static routes" because
no routing protocol is involved. It also seems safe to call
them "classless static routes" since there is no longer any
"classful" netmask associated with IPv4 addresses and there
never was any associated with IPv6 addresses.   

> your document correctly, not a DHCPv6 CSR.

I'll agree that it would be preferrable if IPv4 offered
an option for carrying routing information that could be
inserted by servers and received by relay agents. That
would make for a clean separation of function in which
the client is responsible for reliable message exchanges
and the relay is responsible for managing routes in its
associated networking equipment. But, there are problems
with this when the client and relay reside on the same
device which I will bring up in a separate message.   

> possibly /configured/ into operation via DHCPvX.

There are good reasons to avoid using a routing protocol
in the environment I am concerned with. If there is a
stable aggregation point (or points) inside an operator's
network and many MNs moving about frequently between ARs,
we want to avoid injecting MN-specific routes into the
IGP so that routing churn and IGP convergence latency is
avoided. We can do that if we can confine per-MN routing
updates to just the aggregation points and as side-effect
of the DHCP Solicit/Confirm/Renew/Rebind/etc procedures.

Thanks - Fred

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 14 Nov 2006 19:58:12 +0000

> and/or MNs that do not use DHCP themselves.

That's right, you had relays that had colocated clients.  I
can see how this would create some confusion.

But I still think you're after a DHCPv4 RAAN, and have in your
contrived situation determined to use the CSR for this purpose.

That is, I think everyone who isn't colocating relays with their
clients will have the opposite naming problem.

> no routing protocol is involved. It also seems safe to call

That's not true.  The DHCPv6 RAAN draft explicitly states,
in section 3, 'Option Semantics':

   Examples of use:

   o  Populate an ACL with an assigned IPv6 address if the network
      device in which the relay agent is instantiated implements a
      security policy limiting IPv6 forwarding to devices that have
      obtained an address through DHCP
   o  Inject routing information into a routing infrastructure about a
      delegated prefix on behalf of a requesting router

I agree the DHCPv4 CSR is not expected to fill this purpose,
and no such examples are given, and no one should be encouraged
to use the DHCPv4 CSR for this purpose.

I suspect all the (unfortuante, IMO) reasons everyone has for the
DHCPv6 RAAN are just as applicable to DHCPv4.

> device which I will bring up in a separate message.   

OK.

> in the environment I am concerned with.

That's fair enough.

> If there is a

Please forgive me for speaking as if my own experiences are the
measure of the 'only right way' to operate IP networks, but in
every network I've operated in the past, any architecture that
involved something that looked suspiciously like a routing
protocol - but wasn't - and especially those that looked
suspiciously like maintaining a set of static routes via contrived
dynamic means - was a PITA to debug and maintain.  An operational
nightmare.

So perhaps what I'm trying to say is that I wish you luck, but
I am skeptical that you will find it.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Nov 2006 15:01:41 -0800

David,

Thanks for this; just as follow-up:

- I'll agree that a DHCPv4 RAAN option would probably be
  more suitable than a DHCPv6 CSR option. (But, the nice
  thing about DHCPv4 CSR and DHCPv6 RAAN is that they are
  both already documented.) With this input, plus the "nays"
  I heard at the wg meeting, I'm not going to advocate
  further for any name changes.

- I said I was going to talk about client/relay interaction
  issues in a separate e-mail, but I'm not ready to send
  details on that yet; maybe later. In short, we would like
  to have a way for the co-located client and relay to talk
  to each other via a loopback interface. It appears to work
  fine for DHCPv6, but not so obvious how to make it work
  for DHCPv4 - any ideas?

- About dynamically managing (static) routes, yes that is
  what is being proposed. We need a reliable means for
  getting routing information propagated to the network
  equipment, and DHCP client assures reliability. We also
  need a means for detecting out-of-order delivery, and
  the SRSN option gives us that. (Admittedly, we still
  need something to fit that bill for DHCPv4).

  One way to look at it is that we are overloading DHCP
  to also act as a routing protocol, and maybe that's a
  fair assessment. Another way to look at it is that we
  are reusing widely-deployed mechanisms as a solution
  for the NETLMM problem space, which is the same argument
  successfully made by the Proxy Mobile IP (PMIP) advocates
  who had the largest show-of-hands in the NETLMM consensus
  call. (Although I'm not so sure the "widely-depoyed"
  branding fits MIP as well as it does DHCP?)

Fred

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 11:58 AM
To: [email-masked]
Subject: Re: [dhcwg] dhc WG meeting summay

   Examples of use:

OK.

That's fair enough.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 15 Nov 2006 11:20:51 -0800

> Thanks for this; just as follow-up:

I agree with your summary, we're seeing eye to eye.

>   fine for DHCPv6, but not so obvious how to make it work

Yeah, the idea of 'broadcast' is a bit odd on loopback interfaces,
and critical to rfc2131.  I know our software throws loopbacks out,
as it has to do weird things with BPF in order to transmit rfc2131
compliant packets, and it doesn't make a lot of sense usually to
try and address a loopback interface.

You may need to edge out a dummy interface rather than using
loopback aliases?  I don't know if that'll really help, I've
never tried it, and I'm not sure what software you're using.

If your relay doesn't have an MN-facing address until after the
client has completed, you should be able to use the upstream
address as giaddr, and fill out an RFC3527 link selection sub-option
with the MN-facing network (but this demands prescience of the
MN-facing network's address).

Anyway, I think sufficiently molested software should be able to
make this work.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 15 Nov 2006 11:37:25 -0800

Hi David,

Nothing to add for now, other than that your time and
careful consideration have been very valuable to us.

Now off to see if we can tame these client/relay
interactions...

Thanks - Fred

---

From: Thomas Narten <[email-masked]>
Date: Thu, 16 Nov 2006 08:59:01 -0500

> the list. Reasons to rename the option include:

Without having read the draft, I have to state that my default
starting point is that we do not want to do the above. We have (so
far) intentionally _NOT_ defined a CSR option for DHCPv6. That is what
RAs are for. The main argument against defining a CSR option for IPv6
is that we already have a fine way of doing host routing, namely, via
the RA mechanism. No one expects networks with routers to be deployed
that do not support RAs. Thus, having multiple ways of doing routing
just increases complexity and has no obvious benefits.

Let's please not go here.

Thomas

---

From: "Bonness, Olaf" <[email-masked]>
Date: Thu, 16 Nov 2006 16:20:27 +0100

I have a slightly different feeling regarding a CSR for IPv6. From my
point of view it is more straight forward to have a DHCPv6 option
equivalent to Option 121 for IPv4 when I want to do DHCPv6 PD and want
so signal a dedicated additional Route (that is bound to that prefix)to
the Requesting DHCPv6 Router.
Or is there another solution to this problem, that I'm not aware off?

Tnx and best regards
	Olaf

> -----Ursprungliche Nachricht-----
> Von: Thomas Narten [mailto:[email-masked]]
> Gesendet: Donnerstag, 16. November 2006 14:59
> An: Templin, Fred L
> Cc: dhcwg; Stig Venaas; Ralph Droms
> Betreff: draft-templin-autoconf-netlmm-dhcp [was: Re: [dhcwg] dhc WG
> meeting summay ]
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 16 Nov 2006 08:40:45 -0800

Hi Thomas, 

> far) intentionally _NOT_ defined a CSR option for DHCPv6.

We already had this discussion, and agreed that CSR for
DHCPv6 was not the right fit for our use case. There is
already a DHCPv6 RAAN option that fits the bill for what
we need.

> That is what

I'm not sure how RAs fit into this discussion, and it
would probably be most useful if you were to read the
draft. Routers advertising prefixes to hosts on attached
links is not the use case under consideration.

> Let's please not go here.

We already talked about it here on the list, came to
conclusions, and moved on.

Thanks - Fred

Thomas