Minutes of Remote Boot BOF IETF 44 (Minneapolis, MN) Thursday, March 18, 1999 Minutes reported by Mike Henry and Mike Carney. Agenda: 1. Introduction and agenda bashing Henry 2. Intel's Agenda Henry 3. Proposed Goals of WG Henry 4. Overview of PXE Protocol Henry 5. Use of SLP for bootserver discovery Guttman 6. Next Steps - Areas Needing Work All 2. Intel's Agenda o Establish portions of the PXE 2.0 specification as RFC standards (http://developer.intel.com/ial/wfm/wfmspecs.htm) * remote boot protocol * remote boot mtftp for bootstrap download * IANA registration for - Booting Client types (Instruction Set Architecture) - Bootserver types o Migrate proprietary methods within PXE to IP standards as the standards become available o Provide path for remote boot support in Ipv6 3. Proposed Goals of WG Define a standard protocol between the remote boot client and the responding server(s). The Working Group objective is to produce a protocol that insures remote boot clients, of arbitrary platform and instruction set architecture, will be able to choose an appropriate boot program from an arbitrary variety of boot servers, without the necessity of site-specific pre-configuration of the client. 4. Overview of PXE Protocol Mike Henry gave an overview of the PXE remote boot protocol as defined in the following two drafts: Remote Boot (draft-viswanathan-remote_boot-protocol-00.txt) MTFTP (draft-viswanathan-remote_boot-mtftp-00.txt) [The slides for this presentation have been submitted with these minutes.] Discussion followed: ("C." - comment, "Q." - Question, "A." - Answer) C. Security: something we need to address if we're a working group (Narten) C. The NBP (Network Bootstrap Program) credential transaction is not documented in the draft. C. We need to discuss the deficiencies of the current possibilities (methods) (Narten) Q. TFTP issue raised - some companies will not use tftp (security concern??) So, Appropriate for remote boot use?? A. TFTP is current method for standard DHCP based boot roms. This is not new. Q. Concern about key distribution? A. Only a public key is required for the platform; a private key is not required. Further, the key is owned by the local IT organization. Q. MAC address is writable; are you aligned with IEEE802 body on this issue? A. No. Do we need to be? Not qualified to comment on viability of dynamically writing MAC to guarantee its uniqueness, however, UUID is guaranteed to be unique. C. Suggestion that we send a message to IEEE 802 body to announce our issue C. Concern about use of unique identifiers (UUID as platform ID). Keep that in mind Q. Are PXE strings ASCII? A. (Not sure, check draft. [this was an internationalization motivated question] Q. Is the server supposed to echo back "PXEClient" in Opt 60, or the clients class "PXEClient:Arch:xxx:yyyy")? A. Just "PXEClient" today.... Q. Can you return the entire string? A. Not clear, some DHCP servers do not appear to distinguish between instances of Option 60. Q. Can the client send more identifying info (like kind of SCSI card, etc.) A. This is a Black hole - we decided to let the second level boot program figure out additional HW config information. Q. What does "Intel Order" mean? A. "little endian". 5. Use of SLP for bootserver discovery Eric Guttman gave a short talk on how SLP could be used by the booting to discover a suitable bootserver, even to the extent of accomplishing this without use of a DHCP server. (This would be useful in a "networking in the small" environment.) You could use SLP to locate boot image (bootserver) - e.g. - Platform =0 - UNDI =3 - - Credential = S2 - - UUID --...... Works w/o DHCP +-------------+ | Boot Client | )) --> Attribute request +-------------+ servicetype = remboot ^ attr = platform, authen. Methods | | Attr Reply | (platform = x86, sparc) | +-------------+ +----------------------------| Boot Server | +-------------+ Replace dhcp w/ slp for discovery of bootservers [actually, replace proprietary PXE discovery protocol w/ slp] Q. Can you still encode policy / menu to clients with SLPv2? A. Yes - selection among attributes Must be able to interdict preboot or postboot for administration - SLPv2 can do this - Erik gave other example (Open Group) Q. How to set/determine priority of Boot Servers? A. Could have a priority attribute to communicate to the client which boot image from a group to select. A document describing minimal use of SLP as discovery method for Bootservers is needed to clarify how SLP would work and the extent of change that would be necessary from current method. Eric volunteered to write this up. 6. Next Steps - Areas Needing Work Areas Needing Work 1. Security must be addressed in updated drafts 2. The problem to be solved by a Remote Boot working group must be defined by a requirements document that outlines remote boot requirements and what requirements are currently not addressed. In other words, what is inadequate about what is currently defined? 3. Consideration of Mobile Clients Next Steps 1. Write Requirements Document (Mike Henry, Mike Carney, Marc Blanchet) 2. Investigate current protocols. 3. Decide what is warranted (choose): a. a new standard b. a BCP RFC document use of best use of current standards c. no action; current standards are adequate 4. Need a MIB 5. Write SLP discovery doc. (Eric Guttman)