2.3.11 Remote Boot Protocol (remboot) bof

Current Meeting Report

Minutes of Remote Boot BOF
IETF 44 (Minneapolis, MN)
Thursday, March 18, 1999

Minutes reported by Mike Henry and Mike Carney.


1. Introduction and agenda bashing


2. Intel's Agenda


3. Proposed Goals of WG


4. Overview of PXE Protocol


5. Use of SLP for bootserver discovery


6. Next Steps - Areas Needing Work


2. Intel's Agenda

- Booting Client types (Instruction Set Architecture)
- Bootserver types

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

Next Steps